RFC 1910
User-based Security Model for SNMPv2
Part 1 of 9 🎀
Title Block 📜
okay so this one is RFC 1910, called User-based Security Model for SNMPv2 🦋 It came out of the Network Working Group and was edited by G. Waters from Bell-Northern Research Ltd. in February 1996 💅 It's filed as Experimental, which means it's an experiment, not an internet standard. The header doesn't list anything it obsoletes or updates ✨
Status of This Memo 💌
this memo defines an Experimental Protocol for the Internet community, and it does NOT specify an internet standard of any kind 🙈 the authors are asking for discussion and suggestions for improvement, and the memo can be distributed without limit 🌈
Table of Contents 📚
1. Introduction ................................................ 2
1.1 Threats .................................................... 3
1.2 Goals and Constraints ...................................... 4
1.3 Security Services .......................................... 5
1.4 Mechanisms ................................................. 5
1.4.1 Digest Authentication Protocol ........................... 7
1.4.2 Symmetric Encryption Protocol ............................ 8
2. Elements of the Model ....................................... 10
2.1 SNMPv2 Users ............................................... 10
2.2 Contexts and Context Selectors ............................. 11
2.3 Quality of Service (qoS) ................................... 13
2.4 Access Policy .............................................. 13
2.5 Replay Protection .......................................... 13
2.5.1 agentID .................................................. 14
2.5.2 agentBoots and agentTime ................................. 14
2.5.3 Time Window .............................................. 15
2.6 Error Reporting ............................................ 15
2.7 Time Synchronization ....................................... 16
2.8 Proxy Error Propagation .................................... 16
2.9 SNMPv2 Messages Using this Model ........................... 16
2.10 Local Configuration Datastore (LCD) ....................... 18
3. Elements of Procedure ....................................... 19
3.1 Generating a Request or Notification ....................... 19
3.2 Processing a Received Communication ........................ 20
3.2.1 Additional Details ....................................... 28
3.2.1.1 ASN.1 Parsing Errors ................................... 28
3.2.1.2 Incorrectly Encoded Parameters ......................... 29
3.2.1.3 Generation of a Report PDU ............................. 29
3.2.1.4 Cache Timeout .......................................... 29
3.3 Generating a Response ...................................... 30
4. Discovery ................................................... 30
5. Definitions ................................................. 31
4.1 The USEC Basic Group ....................................... 32
4.2 Conformance Information .................................... 35
4.2.1 Compliance Statements .................................... 35
4.2.2 Units of Conformance ..................................... 35
6. Security Considerations ..................................... 36
6.1 Recommended Practices ...................................... 36
6.2 Defining Users ............................................. 37
6.3 Conformance ................................................ 38
7. Editor's Address ............................................ 38
8. Acknowledgements ............................................ 39
9. References .................................................. 39
Appendix A Installation ........................................ 41
Appendix A.1 Agent Installation Parameters ..................... 41
Appendix A.2 Password to Key Algorithm ......................... 43
Appendix A.3 Password to Key Sample ............................ 441. Introduction 💖
okay so picture a management system 🧚 it's got several (potentially many) nodes, and each one has a processing entity called an agent that can get at management instrumentation. Then there's at least one management station, plus a management protocol that carries management info between the agents and the stations 🫶 everything runs under an administrative framework that defines authentication, authorization, access control, and privacy policies ✨
management stations run management applications that monitor and control managed elements 👑 those are things like hosts, routers, terminal servers, etc., and you watch and control them by getting at their management information 💅
the Administrative Infrastructure for SNMPv2 document [1] defines an administrative framework that makes management work well across a whole bunch of configurations and environments 🌸
inside that framework, a security model is the set of mechanisms that gets you an administratively-defined level of security for protocol interactions 🔐 there could be lots of these models, but this document, User-based Security Model for SNMPv2, is meant to define the first one for this framework, and as of writing it's the only one 🎀
the framework includes an access control model 🙈 enforcing access rights means you need a way to know which entity a request was made on behalf of. so this SNMPv2 security model calls that entity a "user" 💜
1.1. Threats 🦋
a bunch of the classic network protocol threats apply to network management too, so they'd apply to any SNMPv2 security model 😭 other threats don't really apply to network management. this section covers the principal threats, the secondary threats, and the ones that matter less 🍓
the principal threats this SNMPv2 security model should protect against are:
- Modification of Information: the danger that some unauthorized entity alters in-transit SNMPv2 messages that were generated on behalf of an authorized user, in a way that causes unauthorized management operations, including falsifying the value of an object 💀
- Masquerade: the danger that management operations not authorized for some user get attempted by pretending to be a different user who has the right authorizations 🙈
two secondary threats are also identified. the security protocols defined in this memo do provide protection against:
- Message Stream Modification: SNMPv2 is usually built on a connectionless transport service that can run over any subnetwork service 🌈 messages can get re-ordered, delayed, or replayed through the normal operation of lots of subnetwork services. the danger here is that messages get maliciously re-ordered, delayed, or replayed more than normal subnetwork behaviour could cause, in order to pull off unauthorized management operations 😤
- Disclosure: the danger of eavesdropping on exchanges between managed agents and a management station 👀 protecting against this may be required as a matter of local policy 🫣
there are at least two threats that an SNMPv2 security protocol need not protect against. the security protocols defined in this memo do not provide protection against:
- Denial of Service: an SNMPv2 security protocol doesn't need to try to handle the huge range of attacks that deny service to authorized users 😮💨 honestly, these attacks often look exactly like the network failures any viable network management protocol has to deal with as a matter of course 🌧️
- Traffic Analysis: an SNMPv2 security protocol also doesn't need to try to handle traffic analysis attacks 🧐 a lot of traffic patterns are predictable (agents get managed on a regular basis by a relatively small number of management stations), so there's no real advantage in protecting against traffic analysis 💭
1.2. Goals and Constraints 🎯
so based on all those threats in the SNMP environment, the goals of this SNMPv2 security model are as follows ✨
- the protocol should provide for verification that each received SNMPv2 message has not been modified during transmission through the network in a way that could lead to an unauthorized management operation 🔍
- the protocol should provide for verification of the identity of the user on whose behalf a received SNMPv2 message claims to have been generated 🪪
- the protocol should provide for detection of received SNMPv2 messages that request or contain management information and whose time of generation was not recent ⏰
- the protocol should provide, when necessary, that the contents of each received SNMPv2 message are protected from disclosure 🤫
on top of supporting secure network management, the design of this model is also shaped by these constraints 💅
- when the requirements of effective management in times of network stress conflict with those of security, the design should prefer the former 🌪️
- neither the security protocol nor its underlying security mechanisms should depend on the ready availability of other network services (for example, Network Time Protocol (NTP) or key management protocols) 🙅♀️
- a security mechanism should entail no changes to the basic SNMP network management philosophy 🧚
1.3. Security Services 🔐
the security services needed to support the goals of an SNMPv2 security model are these 🫶
- Data Integrity: the property that data hasn't been altered or destroyed in an unauthorized manner, and data sequences haven't been altered to an extent greater than can happen non-maliciously 🛡️
- Data Origin Authentication: the property that the claimed identity of the user on whose behalf received data was originated is corroborated 🪞
- Data Confidentiality: the property that information is not made available or disclosed to unauthorized individuals, entities, or processes 🤐
okay this part is important bestie 🚨 for the protocols in this memo, it is not possible to assure the specific originator of a received SNMPv2 message. instead, what gets authenticated is the user on whose behalf the message was originated 💖
also, for these protocols, it is not possible to get data integrity without data origin authentication, and it is not possible to get data origin authentication without data integrity 🙃 and there's no provision for data confidentiality without both data integrity and data origin authentication 🔗
the security protocols used in this memo are considered acceptably secure at the time of writing 💅 that said, the procedures allow for new authentication and privacy methods to be specified at a future time if the need arises 🦋
1.4. Mechanisms ✨
okay so the security protocols in this memo use a few different mechanisms to hit the goals and security services we just talked about 💅
- In support of data integrity, a message digest algorithm is REQUIRED. A digest gets calculated over an appropriate portion of an SNMPv2 message, and then it's included as part of the message sent to the recipient. 🔐
- In support of data origin authentication and data integrity, a secret value gets inserted into the SNMPv2 message and also appended to it, both before the digest is computed. The inserted value is overwritten before transmission, and the appended value is never transmitted. The secret value is shared by all SNMPv2 entities authorized to originate messages on behalf of the appropriate user. 🤫
- To protect against message delay or replay (to a greater extent than normal operation can cause), a set of time indicators (at the agent) and a request-id are included in each message generated. An SNMPv2 agent evaluates the time indicators to figure out if a received message is recent. An SNMPv2 manager evaluates the time indicators to make sure a received message is at least as recent as the last message it got from the same source. An SNMPv2 manager uses received authentic messages to advance its notion of time (at the agent). An SNMPv2 manager also checks the request-id in received Response messages and discards any messages that don't match outstanding requests. ⏰
Okay now the fine print 👀 These mechanisms catch messages whose time of generation wasn't recent in every case except one. That one is when a Report message (sent to a manager) gets delayed or replayed, and the manager hasn't recently talked to the source of that Report. In that situation, the detection only guarantees that the Report message is more recent than the last communication between the source and destination of the Report message. BUT Report messages don't request or contain management information, so goal #3 in Section 1.2 above is met. Also, Report messages can at most make the manager advance its notion of time (at the agent) by less than the proper amount. Not a disaster, bestie 🫶
This protection against message delay or replay doesn't imply, nor provide, any protection against unauthorized deletion or suppression of messages. 🙅♀️ Other mechanisms defined independently of the security protocol can still be used to detect re-ordering, replay, deletion, or suppression of messages containing set operations (e.g., the MIB variable snmpSetSerialNo [15]).
- In support of data confidentiality, an encryption algorithm is REQUIRED. An appropriate portion of the message gets encrypted before it's transmitted. 🤐
1.4.1. Digest Authentication Protocol 🧁
The Digest Authentication Protocol in this memo provides for:
- verifying the integrity of a received message (i.e., the message received is the message sent). 💯
The integrity of the message is protected by computing a digest over an appropriate portion of a message. The originator computes the digest, transmits it with the message, and the recipient verifies it.
- verifying the user on whose behalf the message was generated. 🪪
A secret value known only to SNMPv2 entities authorized to generate messages on behalf of this user gets inserted into the message and appended to it, both before the digest computation. So the user verification is implicit in the digest verification. (Note that using two copies of the secret, one near the start and one at the end, is RECOMMENDED by [14]. Smart, right? 🧠)
- verifying that a message sent to/from one SNMPv2 entity can't be replayed to/as-if-from another SNMPv2 entity. 🚫
Each message includes an identifier unique to the SNMPv2 agent associated with the sender or intended recipient of the message. Also, each message containing a Response PDU has a request-id that ties it to a recently generated request.
A Report message sent by one SNMPv2 agent to one SNMPv2 manager can potentially be replayed to another SNMPv2 manager. However, Report messages don't request or contain management information, so goal #3 in Section 1.2 above is met. Further, Report messages can at most cause the manager to advance its notion of time (at the agent) by less than the correct amount.
- detecting messages which were not recently generated. 🕰️
A set of time indicators is included in the message, showing the time of generation. Messages (other than those containing Report PDUs) without recent time indicators are not considered authentic. Also, messages containing Response PDUs have a request-id. If the request-id doesn't match that of a recently generated request, the message is not considered authentic.
A Report message sent by an SNMPv2 agent can potentially be replayed at a later time to an SNMPv2 manager that hasn't recently communicated with that agent. However, Report messages don't request or contain management information, so goal #3 in Section 1.2 above is met. Further, Report messages can at most cause the manager to advance its notion of time (at the agent) by less than the correct amount.
This protocol uses the MD5 [3] message digest algorithm. A 128-bit digest is calculated over the designated portion of an SNMPv2 message and included as part of the message sent to the recipient. The size of both the digest carried in a message and the private authentication key is 16 octets. 🔢
This memo allows the same user to be defined on multiple SNMPv2 agents and managers. Each SNMPv2 agent maintains a value, agentID, which uniquely identifies the agent. This value is included in each message sent to/from that agent. Messages sent from a SNMPv2 dual-role entity [1] to a SNMPv2 manager include the agentID value maintained by the dual-role entity's agent. When a message is received, an agent checks the value to make sure it's the intended recipient, and a manager uses the value to make sure the message is processed using the correct state information. 🪄
Each SNMPv2 agent maintains two values, agentBoots and agentTime, which taken together provide an indication of time at that agent. Both of these values are included in an authenticated message sent to/received from that agent. Authenticated messages sent from a SNMPv2 dual-role entity to a SNMPv2 manager include the agentBoots and agentTime values maintained by the dual-role entity's agent. On receipt, the values are checked to make sure the indicated time is within a time window of the current time. The time window represents an administrative upper bound on acceptable delivery delay for protocol messages. ⏳
For an SNMPv2 manager to generate a message which an agent will accept as authentic, and to verify that a message received from that agent is authentic, that manager MUST first achieve time synchronization with that agent. Similarly, for a manager to verify that a message received from an SNMPv2 dual-role entity is authentic, that manager MUST first achieve time synchronization with the dual-role entity's agent. 🔄
1.4.2. Symmetric Encryption Protocol 🔒
The Symmetric Encryption Protocol in this memo provides support for data confidentiality through the use of the Data Encryption Standard (DES) in the Cipher Block Chaining mode of operation. The designated portion of an SNMPv2 message is encrypted and included as part of the message sent to the recipient. 🎀
Two organizations have published specifications defining the DES: the National Institute of Standards and Technology (NIST) [5] and the American National Standards Institute [6]. There's a companion Modes of Operation specification for each definition (see [7] and [8], respectively). 📚
The NIST has published three additional documents that implementors may find useful. 🧐
- There's a document with guidelines for implementing and using the DES, including functional specifications for the DES and its modes of operation [9].
- There's a specification of a validation test suite for the DES [10]. The suite is designed to test all aspects of the DES and is useful for pinpointing specific problems.
- There's a specification of a maintenance test for the DES [11]. The test uses a minimal amount of data and processing to test all components of the DES. It gives a simple yes-or-no indication of correct operation and is useful to run as part of an initialization step, e.g., when a computer reboots.
This Symmetric Encryption Protocol specifies that the size of the privacy key is 16 octets. The first 8 octets are a DES key, and the second 8 octets are a DES Initialization Vector. The 64-bit DES key in the first 8 octets of the private key is a 56-bit quantity used directly by the algorithm, plus 8 parity bits. The parity bits are arranged so that one parity bit is the least significant bit of each octet. The setting of the parity bits is ignored by this protocol. 🔑
The length of an octet sequence to be encrypted by the DES MUST be an integral multiple of 8. When encrypting, the data is padded at the end as necessary, and the actual pad value is irrelevant. 🧩
If the length of the octet sequence to be decrypted is not an integral multiple of 8 octets, the processing of the octet sequence is halted and an appropriate exception is noted. When decrypting, the padding is ignored. 🙈
2. Elements of the Model 🎀
This section contains definitions required to realize the security model defined by this memo. 💜
2.1. SNMPv2 Users 👑
Management operations using this security model make use of a defined set of user identities. For any SNMPv2 user on whose behalf management operations are authorized at a particular SNMPv2 agent, that agent MUST have knowledge of that user. A SNMPv2 manager that wishes to communicate with a particular agent MUST also have knowledge of a user known to that agent, including knowledge of the applicable attributes of that user. Similarly, a SNMPv2 manager that wishes to receive messages from a SNMPv2 dual-role entity MUST have knowledge of the user on whose behalf the dual-role entity sends the message. 🪪
A user and its attributes are defined as follows:
<userName>: An octet string representing the name of the user. 🏷️<authProtocol>: An indication of whether messages sent on behalf of this user can be authenticated, and if so, the type of authentication protocol which is used. One such protocol is defined in this memo: the Digest Authentication Protocol. ✅<authPrivateKey>: If messages sent on behalf of this user can be authenticated, the (private) authentication key for use with the authentication protocol. Note that a user's authentication key will normally be different at different agents. 🗝️<privProtocol>: An indication of whether messages sent on behalf of this user can be protected from disclosure, and if so, the type of privacy protocol which is used. One such protocol is defined in this memo: the Symmetric Encryption Protocol. 🫣
<privPrivateKey> 🔐 okay so, if messages sent on behalf of this user can be protected from disclosure, this is the (private) privacy key used with the privacy protocol. ngl a user's privacy key will normally be different at different agents, so there's no one key that rules them all 👑
2.2. Contexts and Context Selectors 🧩
An SNMPv2 context is a collection of management information that an SNMPv2 agent can reach, either locally or through a proxy 📚 The same item of management information can live in more than one context, and an agent can potentially have access to lots of contexts. Every SNMPv2 message carries a context selector, which unambiguously picks out one SNMPv2 context that the agent receiving the message can access, or that the agent associated with the sender can access. 🎯
For a local SNMPv2 context that's realized by an SNMPv2 entity, that entity uses locally-defined mechanisms to get at the management information in that context 🏠
For a proxy SNMPv2 context, the SNMPv2 entity acts as a proxy SNMPv2 agent to get at the management information in that context 🪞
The term remote SNMPv2 context is used at an SNMPv2 manager for a context (local or proxy) that the local SNMPv2 entity doesn't realize. So the local entity uses neither locally-defined mechanisms nor acts as a proxy SNMPv2 agent for that context 🙅♀️
Proxy SNMPv2 contexts are split up even further, into local-proxy contexts and remote-proxy contexts. A proxy SNMPv2 agent receives Get/GetNext/GetBulk/Set operations for a local-proxy context and forwards them with a remote-proxy context. It receives SNMPv2-Trap and Inform operations for a remote-proxy context and forwards them with a local-proxy context. For Response operations, a proxy SNMPv2 agent receives them with either a local-proxy or remote-proxy context, and forwards them with a remote-proxy or local-proxy context, respectively. 🔄
For the non-proxy situation:
context-A
Manager <----------------> Agentthe type of context is:
+-----------------+
| context-A |
+-----------------+-----------------+
| Manager | remote |
+-----------------+-----------------+
| Agent | local |
+-----------------+-----------------+
| agentID | of Agent |
+-----------------+-----------------+
| contextSelector | locally unique |
+-----------------+-----------------+For proxy:
context-B context-C
Manager <----------------> Proxy <----------------> Agent
Agentthe type and identity of the contexts are:
+-----------------+-----------------+
| context-B | context-C |
+-----------------+-----------------+-----------------+
| Manager | remote | -- |
+-----------------+-----------------+-----------------+
| Proxy-Agent | local-proxy | remote-proxy |
+-----------------+-----------------+-----------------+
| Agent | -- | local |
+-----------------+-----------------+-----------------+
| agentID | of Proxy agent | of Agent |
+-----------------+-----------------+-----------------+
| contextSelector | locally unique | locally unique |
+-----------------+-----------------+-----------------+The combo of an agentID value and a context selector gives you a globally-unique identification of a context 🪪 When a context is accessible by multiple agents (including by proxy SNMPv2 agents, for example), it ends up with multiple globally-unique identifications, one for each agent that can access it. In the example above, context-B and context-C are different names for the same context 👯
2.3. Quality of Service (qoS) 🎀
Messages are generated with a particular Quality of Service (qoS), which is one of:
- without authentication and privacy,
- with authentication but not privacy,
- with authentication and privacy.
Every user can have messages generated on their behalf without authentication and privacy 🫶 Users with an authentication protocol and an authentication key can have messages generated with authentication but not privacy. Users with an authentication protocol, an authentication key, a privacy protocol and a privacy key can have messages generated with authentication and privacy 🔒
On top of its authentication and privacy indications, the qoS may also say that the message contains an operation that may result in a report PDU being generated (see Section 2.6 below) 📣
2.4. Access Policy 🗝️
An administration's access policy decides what access rights its users get 💅 For a particular SNMPv2 context a user can reach using a particular qoS, the user's access rights are a list of authorized operations and, for a local context, a read-view and a write-view. The read-view is the set of object instances the user is authorized to read. Reading happens when processing a retrieval (get, get-next, get-bulk) operation and when sending a notification. The write-view is the set of object instances the user is authorized to write, and writing happens when processing a set operation. A user's access rights may be different at different agents 🌸
2.5. Replay Protection 🛡️
Each SNMPv2 agent (or dual-role entity) maintains three objects:
agentID, which is an identifier unique among all agents in (at least) an administrative domain;agentBoots, which is a count of the number of times the agent has rebooted/re-initialized sinceagentIDwas last configured; and,agentTime, which is the number of seconds sinceagentBootswas last incremented.
An SNMPv2 agent is always authoritative about these variables 👑 It's the responsibility of an SNMPv2 manager to synchronize with the agent, as appropriate. When an SNMPv2 dual-role entity sends an Inform-Request, that entity acting in an agent role is the one that's authoritative about these variables for the Inform-Request 🧠
An agent is required to keep the values of agentID and agentBoots in non-volatile storage 💾
2.5.1. agentID 🪪
The agentID value in an authenticated message is used to defeat attacks where messages from a manager get replayed to a different agent, and/or where messages from one agent (or dual-role entity) get replayed as if they came from a different agent (or dual-role entity) 🕵️♀️
When an agent (or dual-role entity) is first installed, it sets its local value of agentID according to an enterprise-specific algorithm (see the definition of agentID in Section 4.1) ✨
2.5.2. agentBoots and agentTime ⏰
The agentBoots and agentTime values in an authenticated message are used to defeat attacks where messages get replayed when they're no longer valid 🙅♀️ Thanks to agentBoots and agentTime, an SNMPv2 agent doesn't need a non-volatile clock that keeps ticking (i.e., increasing with the passage of time) even when the agent is powered off. Instead, every time an SNMPv2 agent reboots, it retrieves, increments, and then stores agentBoots in non-volatile storage, and resets agentTime to zero 🔁
When an agent (or dual-role entity) is first installed, it sets its local values of agentBoots and agentTime to zero. If agentTime ever reaches its maximum value (2147483647), then agentBoots is incremented as if the agent had rebooted, agentTime is reset to zero, and it starts counting up again 📈
Every time an agent (or dual-role entity) reboots, any SNMPv2 managers holding that agent's agentBoots and agentTime values need to re-synchronize before they send correctly authenticated messages to that agent (see Section 2.7 for re-synchronization procedures). Heads up though: the procedures do allow a notification to be accepted as authentic by a manager, even when it was sent by an agent that has rebooted since the manager last re-synchronized 👀
If an agent (or dual-role entity) is ever unable to determine its latest agentBoots value, then it must set its agentBoots value to 0xffffffff 😱
Whenever the local value of agentBoots is 0xffffffff, it latches at that value, and an authenticated message always causes a usecStatsNotInWindows authentication failure 🚫
To reset an agent whose agentBoots value has reached 0xffffffff, manual intervention is required. Someone has to physically visit the agent and reconfigure it, either with a new agentID value or with new secret values for the authentication and privacy keys of all users known to that agent 🧰
2.5.3. Time Window ⏳
The Time Window is a value that sets the window of time in which a message generated on behalf of any user is valid. This memo specifies that the same Time Window value, 150 seconds, is used for all users 💜
2.6. Error Reporting 🚨
While processing a received communication, an SNMPv2 entity may determine that the message is unacceptable (see Section 3.2). When that happens, the appropriate counter from the snmpGroup [15] or usecStatsGroup object groups is incremented, and the received message is discarded without any further processing 🗑️
If an SNMPv2 entity acting in the agent role makes that kind of determination and the qoS indicates that a report may be generated, then after incrementing the appropriate counter, it is required to generate a message containing a report PDU. That message has the same user and context as the received message, and gets sent to the transport address that originated the received message 📬 For all report PDUs, except the ones generated due to incrementing the usecStatsNotInWindows counter, the report PDU is unauthenticated. For the ones generated due to incrementing usecStatsNotInWindows, the report PDU is authenticated only if the received message was authenticated 🔐
The report flag in the qoS may only be set if the message contains a Get, GetNext, GetBulk, or Set operation. The report flag should never be set for a message that contains a Response, Inform, SNMPv2-Trap or Report operation. And, a report PDU is never sent by an SNMPv2 entity acting in a manager role 🙅♀️💅
2.7. Time Synchronization ⏰
Okay bestie, time sync is giving "we all need to be on the same page or nothing works" 🕰️. A management entity needs time synchronization, which is required before it can proceed with authentic communications. It's officially done once the entity has grabbed local values of agentBoots and agentTime from the agent that sit inside the agent's time window ✨. To stay synced, those local values have to remain inside that window, which means they need to be kept loosely in sync with the values stored over at the agent 💅.
On top of keeping a local copy of agentBoots and agentTime, a manager must also keep one more local variable, latestReceivedAgentTime 🧠. This one tracks the highest agentTime the manager has ever received from the agent. It's there to stop anyone from replaying messages in a way that would freeze the manager's idea of agentTime 🚫.
Time sync happens as part of receiving a message (Section 3.2, step 9d) ✨, so a management entity doesn't need any separate, explicit time sync procedure 🙌. Note, that whenever the local value of agentID gets changed (like through discovery) or a new secret gets configured, the local values of agentBoots and latestReceivedAgentTime should be set to zero 🧹. That way, time sync kicks in on the next authentic message that comes through 📨.
2.8. Proxy Error Propagation 🔁
Picture this: a proxy SNMPv2 agent gets a report PDU from a proxied agent and realizes a proxy-forwarded request can't be delivered to that proxied agent 🙅. So the snmpProxyDrops counter [15] goes up, and a report PDU gets generated and sent to the transport address the original request came from 📬.
Heads up 👀: getting a report PDU that has snmpProxyDrops as a VarBind is one of the reasons a proxy-forwarded request can't be delivered.
2.9. SNMPv2 Messages Using this Model 💌
An SNMPv2 message in this security model is different from an SNMPv1 [2] message in a couple of ways 👀:
- The version component is changed to 2.
- The data component contains either a PDU or an OCTET STRING containing an encrypted PDU.
The SNMPv1 community string got a glow-up and is now called the "parameters" component 💅. It holds a bundle of administrative info for the message ✨.
Only the PDU gets protected from disclosure by the privacy protocol 🔒. That means the admin info is out there for eavesdroppers to see 👀. Misusing that info is considered a Traffic Analysis attack, and no protection is provided against that 🙃.
For an authenticated SNMPv2 message, the message digest covers the entire message handed to the transport service 🧾. So message generation goes like this: privatize the PDU first, then add the message wrapper, then authenticate the whole thing 🎁.
An SNMPv2 message is an ASN.1 value with this syntax 👇:
Message ::=
SEQUENCE {
version
INTEGER { v2 (2) },
parameters
OCTET STRING,
-- <model=1>
-- <qoS><agentID><agentBoots><agentTime><maxSize>
-- <userLen><userName><authLen><authDigest>
-- <contextSelector>
data
CHOICE {
plaintext
PDUs,
encrypted
OCTET STRING
}
}where the breakdown goes like this 🧩:
parameters is a concatenation of the following values in network-byte order. If the first octet (<model>) is one, then:
<qoS>= 8-bits of quality-of-service
bitnumber
7654 3210 meaning
---- ---- --------------------------------
.... ..00 no authentication nor privacy
.... ..01 authentication, no privacy
.... ..1. authentication and privacy
.... .1.. generation of report PDU allowedBit 7 is the most significant bit 👑.
<agentID>= 12 octets: a unique identifier for the agent (or dual-role entity) 🆔.<agentBoots>= 32-bits: an unsigned quantity (0..4294967295) in network-byte order.<agentTime>= 32-bits: an unsigned quantity (0..2147483647) in network-byte order.<maxSize>= 16-bits: an unsigned quantity (484..65507) in network-byte order, which identifies the maximum message size the sender of this message can receive using the same transport domain as used for this message.<userLen>= 1 octet: the length of the following<userName>field.<userName>= 1..16 arbitrary octets: the user on whose behalf this message is sent.<authLen>= 1 octet: the length of the following<authDigest>field.<authDigest>= 0..255 octets: for authenticated messages, the authentication digest. Otherwise, the value has zero-length on transmission and is ignored on receipt.<contextSelector>= 0..40 arbitrary octets: the context selector which, in combination with agentID, identifies the SNMPv2 context containing the management information referenced by the SNMPv2 message.
plaintext: an SNMPv2 PDU as defined in [12] 📄.
encrypted: the encrypted form of an SNMPv2 PDU 🔐.
2.10. Local Configuration Datastore (LCD) 🗄️
Every SNMPv2 entity keeps a local conceptual database called the Local Configuration Datastore (LCD) 📚. It holds what the entity knows about SNMPv2 users, plus other associated info like access control 🔑. An LCD might end up holding info about multiple SNMPv2 agent entities, so the <agentID> should be used to identify a particular agent entity in the LCD 🎯.
Whether LCD info is stored or grabbed dynamically (like through an SNMPv2 manager's API) as needed is a local implementation issue 🛠️.
3. Elements of Procedure 🧩
This section walks through the procedures an SNMPv2 entity follows when it processes SNMPv2 messages 🚶♀️.
3.1. Generating a Request or Notification 📤
This is the procedure an SNMPv2 entity follows whenever it generates a message containing a management operation (either a request or a notification) for a user, for a particular context, and with a particular qoS value 💌.
(1) Information about the user gets pulled from the LCD 🔍. The transport domain and transport address the operation is going to get sent to are figured out. The context gets resolved into an agentID value and a contextSelector value.
(2) If the qoS says the message needs to be protected from disclosure, but the user doesn't support both an authentication and a privacy protocol, or doesn't have configured authentication and privacy keys, then the operation cannot be sent 🚫.
(3) If the qoS says the message needs to be authenticated, but the user doesn't support an authentication protocol, or doesn't have a configured authentication key, then the operation cannot be sent 🚫.
(4) The operation gets serialized (i.e., encoded) following the conventions of [13] and [12] into a PDUs value 🧃.
(5) If the operation is a Get, GetNext, GetBulk, or Set, then the report flag in the qoS is set to the value 1 🚩.
(6) An SNMPv2 message gets constructed using the ASN.1 Message syntax 🧱:
- the version component is set to the value 2.
- if the qoS says the message is to be protected from disclosure, then the octet sequence representing the serialized PDUs value is encrypted according to the user's privacy protocol and privacy key 🔐. The encrypted data gets encoded as an octet string and used as the data component of the message.
- if the qoS says the message is not to be protected from disclosure, then the serialized PDUs value is used directly as the value of the data component.
- the parameters component is constructed using:
- the requested qoS, userName, agentID and context selector,
- if the qoS says the message is to be authenticated, or the management operation is a notification, then the current values of
<agentBoots>and<agentTime>corresponding to agentID from the LCD are used. Otherwise, the<agentBoots>and<agentTime>fields are set to zero-filled octets 🕒. - the
<maxSize>field is set to the maximum message size the local SNMPv2 entity can receive using the transport domain that'll be used to send this message 📏. - if the qoS says the message is to be authenticated, then the
<authDigest>field is temporarily set to the user's authentication key. Otherwise, the<authDigest>field is set to the zero-length string 🗝️.
(7) The constructed Message value gets serialized (i.e., encoded) following the conventions of [13] and [12] 📦.
(8) If the qoS says the message is to be authenticated, then an MD5 digest value is computed over the octet sequence representing the concatenation of the serialized Message value and the user's authentication key 🧮. The <authDigest> field is then set to the computed digest value.
(9) The serialized Message value gets transmitted to the determined transport address 🚀.
3.2. Processing a Received Communication 📥
This is the procedure an SNMPv2 entity follows whenever it receives an SNMPv2 message 📨. It doesn't matter which transport service address the message came in on, since this procedure is independent of that. For clarity, some of the details are left out here and get covered in Section 3.2.1 and its sub-sections 🧁.
(1) The snmpInPkts counter [15] gets incremented. If the received message isn't the serialization (following the conventions of [13]) of a Message value, then the snmpInASNParseErrs counter [15] gets incremented, and the message is discarded without further processing 💥.
(2) If the version component has a value other than 2, then the message is either processed according to some other version of this protocol, or the snmpInBadVersions counter [15] gets incremented, and the message is discarded without further processing 🙅♀️.
(3) The value of the <model> field gets pulled out of the parameters component of the Message value. If the <model> field isn't 1, then either the message is processed according to some other security model, or the usecStatsBadParameters counter is incremented, and the message is discarded without further processing 🗑️.
(4) The values of the rest of the fields get extracted from the parameters component of the Message value 🔎.
(5) If the <agentID> field in the parameters is unknown, then:
- a manager that performs discovery may optionally create a new LCD entry and continue processing; or
- the usecStatsUnknownContexts counter is incremented, a report PDU is generated, and the received message is discarded without further processing 🤷♀️.
(6) The LCD gets consulted for info about the SNMPv2 context identified by the combination of the <agentID> and <contextSelector> fields 🔍. If info about this SNMPv2 context is absent from the LCD, then the usecStatsUnknownContexts counter is incremented, a report PDU is generated, and the received message is discarded without further processing 💀.
(7) okay so the <userName> field gets checked against the LCD for info about that user 🎀. If there's nothing there, the usecStatsUnknownUserNames counter goes up, a report PDU [1] gets generated, and the message is tossed with zero further processing 💀.
(8) If the user's info says they don't support the quality of service in the <qoS> field, then the usecStatsUnsupportedQoS counter goes up, a report PDU gets generated, and the message is discarded without further processing 🙈.
(9) If <qoS> marks the message as authenticated and the user's authentication protocol is the Digest Authentication Protocol from this memo, then:
- a) grab the local values of
agentBootsandagentTimefor the<agentID>from the LCD ✨ - b) save the
<authDigest>value for later 🦋. Then build a brand new serialized Message that's identical to the one received in exactly one way: its<authDigest>field now holds the user's authentication key. Then compute an MD5 digest over the octet sequence of that new serialized Message concatenated with the user's authentication key 🔥. - c) if the LCD says the SNMPv2 context is of type
local(i.e., an agent), then:- if the computed digest is different from the saved
authDigestvalue, theusecStatsWrongDigestValuescounter goes up, a report PDU gets generated, and the message is discarded. Plot twist: if thesnmpEnableAuthenTrapsobject [15] is enabled, the SNMPv2 entity sendsauthenticationFailuretraps [15] according to its configuration 🚨. - if any of these conditions is true, the message counts as outside of the Time Window 👀:
- the local value of
agentBootsis 0xffffffff; - the
<agentBoots>field differs from the local value ofagentBoots; or, - the value of the
<agentTime>field differs from the local notion ofagentTimeby more than +/- 150 seconds.
- the local value of
- if the message is outside of the Time Window, then the
usecStatsNotInWindowscounter goes up, an authenticated report PDU is generated (see section 2.7), and the message is discarded without further processing 😭.
- if the computed digest is different from the saved
- d) if the LCD says the SNMPv2 context is not realized by the local SNMPv2 entity (i.e., a manager), then:
- if the computed digest is different from the saved
authDigestvalue, theusecStatsWrongDigestValuescounter goes up and the message is discarded without further processing. - if all of the following conditions are true:
- the
<qoS>field indicates that privacy is not in use; - the SNMPv2 operation type, determined from the ASN.1 tag value of the PDU's component, is a Report;
- the Report was generated because of a
usecStatsNotInWindowserror condition; and, - the
<agentBoots>field is greater than the local value ofagentBoots, or the<agentBoots>field equals the local value ofagentBootsand the<agentTime>field is greater than the value oflatestReceivedAgentTime,
- the
- if the computed digest is different from the saved
then the LCD entry for the <agentID> field gets updated: the local agentBoots is set from <agentBoots>, latestReceivedAgentTime is set from <agentTime>, and the local agentTime is set from <agentTime> 🌸.
- if any of these conditions is true, the message counts as outside of the Time Window:
- the local value of
agentBootsis 0xffffffff; - the
<agentBoots>field is less than the local value ofagentBoots; or, - the
<agentBoots>field equals the local value ofagentBootsand the<agentTime>field is more than 150 seconds less than the local notion ofagentTime.
- the local value of
- if the message is outside of the Time Window, then the
usecStatsNotInWindowscounter goes up and the message is discarded without further processing. However, time synchronization procedures may be invoked. Also note that this procedure lets<agentBoots>be greater than the local value ofagentBoots, so messages from an agent that rebooted since the manager last re-synchronized can still be accepted as authentic 🔄. - if at least one of these conditions is true:
- the
<agentBoots>field is greater than the local value ofagentBoots; or, - the
<agentBoots>field equals the local value ofagentBootsand the<agentTime>field is greater than the value oflatestReceivedAgentTime,
- the
then the LCD entry for the <agentID> field gets updated: the local agentBoots is set from <agentBoots>, the local latestReceivedAgentTime is set from <agentTime>, and the local agentTime is set from <agentTime> 💜.
(10) If <qoS> indicates use of a privacy protocol, then the octet sequence for the data component gets decrypted using the user's privacy protocol to get a serialized PDUs value 🔐. Otherwise, the data component is assumed to contain the PDUs value directly.
(11) The SNMPv2 operation type is determined from the ASN.1 tag value of the PDUs component 🏷️.
(12) If the SNMPv2 operation type is a Report, then the request-id in the PDU gets correlated to an outstanding request. If that works, the right action is taken (e.g., time synchronization, proxy error propagation, etc.). Especially, if the report PDU indicates a usecStatsNotInWindows condition, the outstanding request may be retransmitted, since the procedure in Step 9d above should have led to time synchronization ⏰.
(13) If the SNMPv2 operation type is a Get, GetNext, GetBulk, or Set operation, then:
- a) if the LCD says the SNMPv2 context is of type remote or remote-proxy, the
usecStatsUnauthorizedOperationscounter goes up, a report PDU is generated, and the message is discarded without further processing 🚫. - b) the LCD gets consulted for the access rights allowed for communications using the indicated qoS, on behalf of the indicated user, and about management information in the indicated SNMPv2 context for that particular operation type 🔍.
- c) if the SNMPv2 operation type is not among the authorized access rights, the
usecStatsUnauthorizedOperationscounter goes up, a report PDU is generated, and the message is discarded without further processing. - d) the info pulled from the LCD about the user and the SNMPv2 context, together with the sending transport address of the received message, gets cached for later use when generating a response message 🗂️.
- e) if the LCD says the SNMPv2 context is of type local, then the management operation represented by the PDUs value is performed by the receiving SNMPv2 entity on the relevant MIB view within the SNMPv2 context, following the procedures in [12]. The relevant MIB view is determined by the user, the
agentID, thecontextSelector, the qoS values, and the type of operation requested 🎯. - f) if the LCD says the SNMPv2 context is of type local-proxy, then:
- i. the user, qoS,
agentID,contextSelector, and transport address to be used for forwarding the request get extracted from the LCD. If there isn't enough info about the user available right now, thesnmpProxyDropscounter [15] goes up, a report PDU is generated, and the message is discarded 😵. - ii. if an administrative flag in the LCD says the message is to be forwarded using the SNMPv1 administrative framework, then the procedures described in [4] get invoked. Otherwise, a new SNMPv2 message is constructed: its PDUs component is copied from the received message, except the request-id gets replaced by a unique value (so a later response can be correlated with this request) 🪄. The
<userName>,<qoS>,<agentID>, and<contextSelector>fields are set to the values from the LCD. The<maxSize>field is set to the smaller of the value in the received message and the local system's maximum message size for the transport domain that'll be used to forward the message. Finally, the message is authenticated and/or protected from disclosure according to the qoS value 🔒. - iii. the info cached in Step 13d above gets augmented with the request-id of the received message, plus the request-id,
agentID, andcontextSelectorof the constructed message 📝. - iv. the constructed message gets forwarded to the extracted transport address 🚀.
- i. the user, qoS,
(14) If the SNMPv2 operation type is an Inform, then:
- a) okay so if the LCD says the SNMPv2 context is
localorlocal-proxy, then theusecStatsUnauthorizedOperationscounter gets incremented, a report PDU gets generated, and the received message is discarded without further processing 🙅♀️ not it 💅 - b) if the LCD says the context is
remote, then the Inform operation in the PDUs value is performed by the receiving SNMPv2 entity following the procedures in [12] 🦋 - c) if the LCD says the context is
remote-proxy, then:- i. a single unique request-id gets picked for all the forwarded copies of this request 🎀 this value lets the first response get matched back to this request. other responses are not required, and they should be discarded when received, since the agent that originated the Inform only needs one response to its Inform 🫶
- ii. info gets pulled from the LCD about every combination of
<userName>,<qoS>,<agentID>,<contextSelector>and transport address that the received message is going to be forwarded with 🗺️ - iii. for each combo whose access rights let Inform operations get forwarded, a brand new SNMPv2 message gets built ✨ its PDUs component is copied from the received message, except the request-id gets swapped for the value picked in Step i above. then its
<userName>,<qoS>,<agentID>and<contextSelector>fields are set to the values pulled in Step ii above. and its<maxSize>field is set to the minimum of the value in the received message and the local system's maximum message size for the transport domain that will be used to forward this message 💖 - iv. for each constructed SNMPv2 message, the info about the
<userName>,<qoS>,<agentID>,<contextSelector>, request-id and sending transport address of the received message gets cached, along with the request-id, agentID and contextSelector of the constructed message. this is saved for later, so a response can be generated 🧠 - v. each constructed message gets forwarded to the right transport address that was pulled from the LCD in step ii above 🚀
(15) If the SNMPv2 operation type is a Response, then:
- a) if the LCD says the context is
local, then theusecStatsUnauthorizedOperationscounter gets incremented, a report PDU gets generated, and the received message is discarded without further processing. nope nope nope 🙅♀️ - b) if the LCD says the context is
remote, then the Response operation in the PDUs value is performed by the receiving SNMPv2 entity following the procedures in [12] 💅 - c) if the LCD says the context is
local-proxyorremote-proxy, then:- i. the request-id gets extracted from the PDUs component of the received message 🔎 the context's agentID and contextSelector values, plus that request-id, get used to match this response to the matching values of a request that was forwarded before. the match is made by checking the cache, which was filled in Substep iii of Step 13f above or in Substep iv of 14c above 🗃️ if no matching info is found, then the received message is discarded without further processing 🗑️
- ii. a new SNMPv2 message gets constructed. its PDUs component is copied from the received message, except the request-id gets swapped for the value saved in the matched info from the original request. its
<userName>,<qoS>,<agentID>and<contextSelector>fields are set to the values saved from the received message. the<maxSize>field is set to the minimum of the value in the received message and the local system's maximum message size for the transport domain that will be used to forward the message. then the message is authenticated and/or protected from disclosure, according to the saved qoS value 🔐 - iii. the constructed message gets forwarded to the transport address saved in the matched info, which is the sending transport address of the original request 📬
- iv. the matched info gets deleted from the cache 🧹
(16) If the SNMPv2 operation type is a SNMPv2-Trap, then:
- a) if the LCD says the context is
localorlocal-proxy, then theusecStatsUnauthorizedOperationscounter gets incremented, a report PDU gets generated, and the received message is discarded without further processing 🙅♀️ - b) if the LCD says the context is
remote, then the SNMPv2-Trap operation in the PDUs value is performed by the receiving SNMPv2 entity following the procedures in [12] 🌈 - c) if the LCD says the context is
remote-proxy, then:- i. a unique request-id gets picked to use when forwarding the message 🎯
- ii. info gets pulled from the LCD about every combination of
<userName>,<qoS>,<agentID>,<contextSelector>and transport address that the received message is going to be forwarded with 🗺️ - iii. for each combo whose access rights let SNMPv2-Trap operations get forwarded, a new SNMPv2 message gets built. its PDUs component is copied from the received message, except the request-id gets swapped for the value picked in Step i above. then its
<userName>,<qoS>,<agentID>and<contextSelector>fields are set to the values pulled in Step ii above 🧁 - iv. each constructed message gets forwarded to the right transport address that was pulled from the LCD in step ii above 🚀
3.2.1. Additional Details 🌸
For the sake of clarity, and to keep the above procedure from getting even longer, a few details were left out of it. Here they are 🫶
3.2.1.1. ASN.1 Parsing Errors
For ASN.1 parsing errors, the snmpInASNParseErrs counter [15] gets incremented, and a report PDU gets generated whenever one of these errors is found. BUT, if the parsing error means there's not enough info left to build a report PDU, then the report PDU doesn't get sent 😭
3.2.1.2. Incorrectly Encoded Parameters
For an incorrectly encoded parameters component of the Message value (like an incorrect or inconsistent value in the <userLen> or <authLen> fields), the usecStatsBadParameters counter gets incremented. Since the encoded parameters are wrong, the report flag in the qoS can't be reliably determined. So no report PDU gets generated for this incorrectly encoded parameters error 🙈
3.2.1.3. Generation of a Report PDU
Some steps say the received message is discarded without further processing whenever a report PDU is generated. However:
- An SNMPv2 manager never generates a report PDU. 🙅♀️
- If the operation type can reliably be determined, and it's determined to be a Report, SNMPv2-Trap, Inform, or a Response, then a report PDU is not generated. 🚫
- A report PDU is only generated when the report flag in the qoS is set to the value 1. 🚩
A generated report PDU must always use the current values of agentID, agentBoots, and agentTime from the LCD. On top of that, a generated report PDU must whenever possible contain the same request-id value as the PDU in the received message. Meeting this usually means the message has to be processed just enough to pull out its request-id. There are two situations where the SNMPv2 request-id can't be determined. The first is when the userName is unknown and the qoS says the message is encrypted. The other is when there's an ASN.1 parsing error. When the request-id can't be determined, the default request-id value 2147483647 is used 🔢
3.2.1.4. Cache Timeout
Some steps say info gets cached so a Response operation can be matched to the right Request operation. But a few situations could make the cache grow forever 😱 One of them is when the Response operation never shows up, or shows up "late" at the entity. So to make sure the cache doesn't grow without bound, it is recommended that cache entries get deleted when they're no longer valid. How long cache entries stay valid is an implementation dependent decision. However, caching entries for more than 150 seconds is not useful, since any use of the cache entry after that time would generate a usecStatsNotInWindows error condition ⏰
3.3. Generating a Response 💌
The procedure for generating a response to an SNMPv2 management request is identical to the procedure for transmitting a request (see Section 3.1), with these exceptions:
- The response is sent on behalf of the same user, and with the same value of the agentID and contextSelector as the request. 👯
- The PDUs value of the responding Message value is the response that results from performing the operation specified in the original PDUs value. 🎁
- The authentication protocol and other relevant info for the user is obtained, not from the LCD, but from info cached (in Step 13d) when the original message was processed. 🗃️
- The serialized Message value is transmitted using any transport address that belongs to the agent for the transport domain the corresponding request came from, even if that's different from any transport info obtained from the LCD. 🛰️
- If the qoS says the message is to be authenticated, or the response is being generated by an SNMPv2 entity acting in an agent role, then the current values of agentBoots and agentTime from the LCD are used. Otherwise, the
<agentBoots>and<agentTime>fields are set to zero-filled octets. 🧊 - The report flag in the qoS is set to the value 0. 🙌
4. Discovery 🔍
This security model requires that a discovery process gets enough info about an SNMPv2 entity's agent to communicate with it. Discovery requires the SNMPv2 manager to learn the agent's agentID value before communication can go ahead. This can be done by formulating a get-request communication with the qoS set to noAuth/noPriv, the userName set to "public", the agentID set to all zeros (binary), the contextSelector set to "", and the VarBindList left empty 🫧 The response to this message is a reportPDU that contains the agentID within the <parameters> field (and it contains the usecStatsUnknownContexts counter in the VarBindList). If authenticated communication is required, then the discovery process may invoke the procedure described in Section 2.7 to synchronize the clocks ⏱️
5. Definitions 📜
SNMPv2-USEC-MIB DEFINITIONS ::= BEGINOkay, the MIB module is next 💅
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, Counter32, Unsigned32,
snmpModules
FROM SNMPv2-SMI
TEXTUAL-CONVENTION
FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF;
usecMIB MODULE-IDENTITY
LAST-UPDATED "9601120000Z"
ORGANIZATION "IETF SNMPv2 Working Group"
CONTACT-INFO
" Glenn W. Waters
Postal: Bell-Northern Research, Ltd.
P.O. Box 3511, Station C
Ottawa, ON, K1Y 4H7
Canada
Tel: +1 613 763 3933
E-mail: gwaters@bnr.ca"
DESCRIPTION
"The MIB module for SNMPv2 entities implementing the user-
based security model."
::= { snmpModules 6 }
usecMIBObjects OBJECT IDENTIFIER ::= { usecMIB 1 }
-- Textual Conventions
AgentID ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"An agent's administratively-unique identifier.
The value for this object may not be all zeros or all 'ff'H.
The initial value for this object may be configured via an
operator console entry or via an algorithmic function. In
the later case, the following guidelines are recommended:
1) The first four octets are set to the binary equivalent
of the agent's SNMP network management private
enterprise number as assigned by the Internet Assigned
Numbers Authority (IANA). For example, if Acme
Networks has been assigned { enterprises 696 }, the
first four octets would be assigned '000002b8'H.
2) The remaining eight octets are the cookie whose
contents are determined via one or more enterprise-
specific methods. Such methods must be designed so as
to maximize the possibility that the value of this
object will be unique in the agent's administrative
domain. For example, the cookie may be the IP address
of the agent, or the MAC address of one of the
interfaces, with each address suitably padded with
random octets. If multiple methods are defined, then
it is recommended that the cookie be further divided
into one octet that indicates the method being used and
seven octets which are a function of the method."
SYNTAX OCTET STRING (SIZE (12))
-- the USEC Basic group
--
-- a collection of objects providing basic instrumentation of
-- the SNMPv2 entity implementing the user-based security model
usecAgent OBJECT IDENTIFIER ::= { usecMIBObjects 1 }
agentID OBJECT-TYPE
SYNTAX AgentID
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The agent's administratively-unique identifier."
::= { usecAgent 1 }
agentBoots OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of times that the agent has re-initialized
itself since its initial configuration."
::= { usecAgent 2 }
agentTime OBJECT-TYPE
SYNTAX Unsigned32 (0..2147483647)
UNITS "seconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of seconds since the agent last incremented the
agentBoots object."
::= { usecAgent 3 }
agentSize OBJECT-TYPE
SYNTAX INTEGER (484..65507)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The maximum length in octets of an SNMPv2 message which
this agent will accept using any transport mapping."
::= { usecAgent 4 }
-- USEC statistics
--
-- a collection of objects providing basic instrumentation of
-- the SNMPv2 entity implementing the user-based security model
usecStats OBJECT IDENTIFIER ::= { usecMIBObjects 2 }
usecStatsUnsupportedQoS OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of packets received by the SNMPv2 entity
which were dropped because they requested a quality-of-
service that was unknown to the agent or otherwise
unavailable."
::= { usecStats 1 }
usecStatsNotInWindows OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of packets received by the SNMPv2 entity
which were dropped because they appeared outside of the
agent's window."
::= { usecStats 2 }
usecStatsUnknownUserNames OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of packets received by the SNMPv2 entity
which were dropped because they referenced a user that was
not known to the agent."
::= { usecStats 3 }
usecStatsWrongDigestValues OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of packets received by the SNMPv2 entity
which were dropped because they didn't contain the expected
digest value."
::= { usecStats 4 }
usecStatsUnknownContexts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of packets received by the SNMPv2 entity
which were dropped because they referenced a context that
was not known to the agent."
::= { usecStats 5 }
usecStatsBadParameters OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of packets received by the SNMPv2 entity
which were dropped because the <parameters> field was
improperly encoded or had invalid syntax."
::= { usecStats 6 }
usecStatsUnauthorizedOperations OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of packets received by the SNMPv2 entity
which were dropped because the PDU type referred to an
operation that is invalid or not authorized."
::= { usecStats 7 }
-- conformance information
usecMIBConformance
OBJECT IDENTIFIER ::= { usecMIB 2 }
usecMIBCompliances
OBJECT IDENTIFIER ::= { usecMIBConformance 1 }
usecMIBGroups OBJECT IDENTIFIER ::= { usecMIBConformance 2 }
-- compliance statements
usecMIBCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMPv2 entities which
implement the SNMPv2 USEC model."
MODULE -- this module
MANDATORY-GROUPS { usecBasicGroup,
usecStatsGroup }
::= { usecMIBCompliances 1 }
-- units of conformance
usecBasicGroup OBJECT-GROUP
OBJECTS { agentID,
agentBoots,
agentTime,
agentSize }
STATUS current
DESCRIPTION
"A collection of objects providing identification, clocks,
and capabilities of an SNMPv2 entity which implements the
SNMPv2 USEC model."
::= { usecMIBGroups 1 }
usecStatsGroup OBJECT-GROUP
OBJECTS { usecStatsUnsupportedQoS,
usecStatsNotInWindows,
usecStatsUnknownUserNames,
usecStatsWrongDigestValues,
usecStatsUnknownContexts,
usecStatsBadParameters,
usecStatsUnauthorizedOperations }
STATUS current
DESCRIPTION
"A collection of objects providing basic error statistics of
an SNMPv2 entity which implements the SNMPv2 USEC model."
::= { usecMIBGroups 2 }
END6. Security Considerations 🔒
6.1. Recommended Practices
This section lays out practices that help keep the mechanisms in this memo secure and working well 🫶
- A management station must throw out any SNMPv2 response where neither the request-id component nor the represented management information matches anything that's still an outstanding request 🙅♀️ Sure, it's typical for a management station to do this as a matter of course, but when you're using these security protocols it's significant, because of the possibility of message duplication (malicious or otherwise) 👀
- A management station must generate unpredictable request-ids in authenticated messages, so it's protected against message duplication (malicious or otherwise) 🎀
- A management station should do time synchronization using authenticated messages, to protect against the possibility of message duplication (malicious or otherwise) ⏰
- When sending state altering messages to a managed agent, a management station should delay sending successive messages to that agent until a positive acknowledgement comes back for the previous message, or until the previous message expires 🚦
No message ordering is imposed by the SNMPv2 🙃 Messages may be received in any order relative to their time of generation, and each will be processed in the order received. Heads up: when an authenticated message is sent to a managed agent, it's valid for approximately 150 seconds under normal circumstances, and it's subject to replay during that window 🔁 Honestly, a management station must cope with the loss and re-ordering of messages that come from anomalies in the network as a matter of course. However, a managed object, snmpSetSerialNo [15], is specifically defined for use with SNMPv2 set operations, to give a mechanism that ensures SNMPv2 messages are processed in a specific order ✨
- The frequency with which an SNMPv2 user's secrets should be changed is indirectly related to how often they get used 🔐
Protecting the secrets from disclosure is critical to the overall security of the protocols 🛡️ Frequent use of a secret provides a continued source of data that may be useful to a cryptanalyst trying to exploit known or perceived weaknesses in an algorithm. Frequent changes to the secret avoid this vulnerability.
Changing a secret after each use is generally regarded as the most secure practice, but a significant amount of overhead may be associated with that approach 😤
Note, too: in a local environment the threat of disclosure may be less significant, so the changing of secrets may be less frequent. However, when public data networks are the communication paths, more caution is prudent 🚨
6.2. Defining Users 💅
okay so this whole section is about "users" having access rights 🔑, and ngl, what counts as a "user" is up to the network admin's security policy 🫶. a user could be an actual person (hi "joe" and "jane" 💖), a role like "operator" or "administrator" 👑, or a combo like "joe-operator", "jane-operator" or "joe-admin" ✨. a "user" can even be a logical entity, like a manager station app (or a whole set of them 🧚) acting on behalf of an individual, a role, a set of individuals, a set of roles, or any combo of those. it's giving flexible energy.
Appendix A explains how to turn a user "password" into a 16 octet value 🎀 that works as an authentication key, a privacy key, or both. but here's the tea ☕: passwords are usually made up, remembered and typed in by a human 🙈, and human passwords can be shorter than the 16 octets the authentication and privacy protocols need. brute force attacks can also be pretty easy on a short ASCII character set 💀. so the Appendix A algorithm does a transformation on the password 🦋. if you're using the Appendix A algorithm, agent implementations (and agent configuration applications) MUST ensure that passwords are at least 8 characters in length 🔥.
since the Appendix A algorithm uses these passwords (nearly) directly, it is SUPER important that they're not easy to guess 👀. the suggestion is mixed-case letters and numbers plus punctuation, with no words or phrases a dictionary would have 📖🚫. longer passwords make the system more secure 💪. users may wish to type in multiword phrases to make the password longer while still being memorable 🌸.
😭 heads up: if you set up the same "user" on multiple systems using the SAME password, one leaked secret means that user is compromised on every other system that uses that password too.
the Appendix A algorithm dodges that problem by mixing the agent's agentID value in with the user's password when it calculates the user's secrets 🧠. so the secrets come out different at each agent ✨. BUT if the password itself gets compromised, the Appendix A algorithm is not effective. 💔
6.3. Conformance 🎀
okay, so to be called a "Secure SNMPv2 implementation", an SNMPv2 implementation:
- MUST implement the Digest Authentication Protocol. 🔐
- MUST, to the maximal extent possible, prohibit access to the secret(s) of each user about which it maintains information in a LCD, under all circumstances except as required to generate and/or validate SNMPv2 messages with respect to that user. 🙅♀️
- MUST implement the SNMPv2 USEC MIB. 💜
and on top of that, an SNMPv2 agent MUST provide initial configuration in accordance with Appendix A.1 ⚙️.
Implementation of the Symmetric Encryption Protocol is OPTIONAL. 🦋
7. Editor's Address 💌
Glenn W. Waters Bell-Northern Research Ltd. P.O. Box 3511, Station C Ottawa, Ontario K1Y 4H7 CA
Phone: +1 613 763 3933 EMail: gwaters@bnr.ca
8. Acknowledgements 🫶
this document is the result of some seriously big work by three major contributors 👑:
- Keith McCloghrie (Cisco Systems, kzm@cisco.com)
- Marshall T. Rose (Dover Beach Consulting, mrose@dbc.mtview.ca.us)
- Glenn W. Waters (Bell-Northern Research Ltd., gwaters@bnr.ca)
the authors want to give a shout-out to James M. Galvin of Trusted Information Systems, who did a lot of the earlier work this memo is based on 🙌. they also thank the SNMPv2 Working Group members in general, and especially Aleksey Y. Romanov and Steven L. Waldbusser 💜.
and a super special thanks goes to:
- Uri Blumenthal (IBM)
- Shawn Routhier (Epilogue)
- Barry Sheehan (IBM)
- Bert Wijnen (IBM)
9. References 📚
[1] McCloghrie, K., Editor, "An Administrative Infrastructure for SNMPv2", RFC 1909, Cisco Systems, January 1996.
[2] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, SNMP Research, Performance Systems International, MIT Laboratory for Computer Science, May 1990.
[3] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, MIT Laboratory for Computer Science, April 1992.
[4] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework", RFC 1908, January 1996.
[5] Data Encryption Standard, National Institute of Standards and Technology. Federal Information Processing Standard (FIPS) Publication 46-1. Supersedes FIPS Publication 46, (January, 1977; reaffirmed January, 1988).
[6] Data Encryption Algorithm, American National Standards Institute. ANSI X3.92-1981, (December, 1980).
[7] DES Modes of Operation, National Institute of Standards and Technology. Federal Information Processing Standard (FIPS) Publication 81, (December, 1980).
[8] Data Encryption Algorithm - Modes of Operation, American National Standards Institute. ANSI X3.106-1983, (May 1983).
[9] Guidelines for Implementing and Using the NBS Data Encryption Standard, National Institute of Standards and Technology. Federal Information Processing Standard (FIPS) Publication 74, (April, 1981).
[10] Validating the Correctness of Hardware Implementations of the NBS Data Encryption Standard, National Institute of Standards and Technology. Special Publication 500-20.
[11] Maintenance Testing for the Data Encryption Standard, National Institute of Standards and Technology. Special Publication 500-61, (August, 1980).
[12] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S., Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996.
[13] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996.
[14] Krawczyk, H., "Keyed-MD5 for Message Authentication", Work in Progress, IBM, June 1995.
[15] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1907 January 1996.
APPENDIX A - Installation 🧚
A.1. Agent Installation Parameters ✨
during installation, an agent gets configured with a few parameters 🛠️. these include:
(1) a security posture
the security posture decides how big the view for unauthenticated access is. one of three choices gets picked: minimum-secure, semi-secure, or very-secure 🎯.
(2) one or more transport service addresses
these parameters may be set explicitly, or they may be set implicitly as the same set of network-layer addresses the device already uses for other stuff, together with the well-known transport-layer "port" info for the right transport domain [13] 🌐. the agent listens on each of these transport service addresses for messages sent on behalf of any user it knows about 👂.
(3) one or more secrets
these are the authentication/privacy secrets for the first user to be configured 🔑.
one way to do this is to have the installer enter a "password" for each required secret. then the password gets algorithmically converted into the required secret by:
- forming a string of length 1,048,576 octets by repeating the value of the password as often as necessary, truncating accordingly, and using the resulting string as the input to the MD5 algorithm. the resulting digest, termed "digest1", is used in the next step. 🧮
- a second string of length 44 octets is formed by concatenating digest1, the agent's agentID value, and digest1. this string is used as input to the MD5 algorithm. the resulting digest is the required secret (see Appendix A.2). ✨
with these configured parameters, the agent sets up the following user, context, views and access rights. this configuration information SHOULD be readOnly (persistent) 🔒.
- One user:
privacy not supported privacy supported
--------------------- -----------------
<userName> "public" "public"
<authProtocol> Digest Auth. Protocol Digest Auth. Protocol
<authPrivateKey> authentication key authentication key
<privProtocol> none Symmetric Privacy Protocol
<privPrivateKey> -- privacy key- One local context with its
<contextSelector>as the empty-string. 🧁 - One view for authenticated access:
- the
<all>MIB view is the "internet" subtree. 🌈
- the
- A second view for unauthenticated access. This view is configured according to the selected security posture. For the "very-secure" posture:
- the
<restricted>MIB view is the union of the "snmp" [15], "usecAgent" and "usecStats" subtrees. 🔐
- the
For the "semi-secure" posture:
- the
<restricted>MIB view is the union of the "snmp" [15], "usecAgent", "usecStats" and "system" subtrees. 🦋
For the "minimum-secure" posture:
- the
<restricted>MIB view is the "internet" subtree. 🌸
- Access rights to allow:
- read-only access for unauthenticated messages on behalf of the user "public" to the
<restricted>MIB view of contextSelector "". 👀 - read-write access for authenticated but not private messages on behalf of the user "public" to the
<all>MIB view of contextSelector "". 💅 - if privacy is supported, read-write access for authenticated and private messages on behalf of the user "public" to the
<all>MIB view of contextSelector "". 👑
- read-only access for unauthenticated messages on behalf of the user "public" to the
A.2. Password to Key Algorithm 🔐
the following code fragment shows the password to key algorithm, which can be used when mapping a password to an authentication or privacy key 🗝️. (the calls to MD5 are as documented in RFC 1321.)
void password_to_key(password, passwordlen, agentID, key)
u_char *password; /* IN */
u_int passwordlen; /* IN */
u_char *agentID; /* IN - pointer to 12 octet long agentID */
u_char *key; /* OUT - caller supplies pointer to 16
octet buffer */ {
MD5_CTX MD;
u_char *cp, password_buf[64];
u_long password_index = 0;
u_long count = 0, i;
MD5Init (&MD); /* initialize MD5 */
/* loop until we've done 1 Megabyte */
while (count < 1048576) {
cp = password_buf;
for(i = 0; i < 64; i++) {
*cp++ = password[ password_index++ % passwordlen ];
/*
* Take the next byte of the password, wrapping to the
* beginning of the password as necessary.
*/
}
MDupdate (&MD, password_buf, 64);
count += 64;
}
MD5Final (key, &MD); /* tell MD5 we're done */
/* localize the key with the agentID and pass through MD5
to produce final key */
memcpy (password_buf, key, 16);
memcpy (password_buf+16, agentID, 12);
memcpy (password_buf+28, key, 16);
MD5Init (&MD);
MDupdate (&MD, password_buf, 44);
MD5Final (key, &MD);
return; }A.3. Password to Key Sample ✨
Okay so here's a sample run of the password to key algorithm, bestie 🔐💖 It's giving a clear before-and-after moment.
With a password of "maplesyrup" 🍁, the output of the password to key algorithm before the key gets localized with the agent's agentID comes out to:
'9f af 32 83 88 4e 92 83 4e bc 98 47 d8 ed d9 63'HThen the intermediate key (the one above) gets localized with the agentID value of:
'00 00 00 00 00 00 00 00 00 00 00 02'Hand the final output of the password to key algorithm is:
'52 6f 5e ed 9f cc e2 6f 89 64 c2 93 07 87 d8 2b'HMain character energy, literally 💅🦋
📦 where this page comes from
- ietf: rfc1910 1996-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms