RFC 1446

Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2)

📅 published April 1993, from ietf

okay bestie, we're doing RFC 1446 today 🎀✨

RFC 1446: Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2) 💜

Network Working Group, April 1993. Authors: J. Galvin (Trusted Information Systems) and K. McCloghrie (Hughes LAN Systems). This is an IAB standards track protocol, so it's a real official spec, not just vibes 🔥

Status of this Memo 🌸

This RFC specifies an IAB standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements. For the standardization state and status of this protocol, check the current edition of the "IAB Official Protocol Standards." Distribution of this memo is unlimited 💅

Table of Contents 📋

          1 Introduction ..........................................    2
          1.1 A Note on Terminology ...............................    3
          1.2 Threats .............................................    4
          1.3 Goals and Constraints ...............................    5
          1.4 Security Services ...................................    6
          1.5 Mechanisms ..........................................    7
          1.5.1 Message Digest Algorithm ..........................    8
          1.5.2 Symmetric Encryption Algorithm ....................    9
          2 SNMPv2 Party ..........................................   11
          3 Digest Authentication Protocol ........................   14
          3.1 Generating a Message ................................   16
          3.2 Receiving a Message .................................   18
          4 Symmetric Privacy Protocol ............................   21
          4.1 Generating a Message ................................   21
          4.2 Receiving a Message .................................   22
          5 Clock and Secret Distribution .........................   24
          5.1 Initial Configuration ...............................   25
          5.2 Clock Distribution ..................................   28
          5.3 Clock Synchronization ...............................   29
          5.4 Secret Distribution .................................   31
          5.5 Crash Recovery ......................................   34
          6 Security Considerations ...............................   37
          6.1 Recommended Practices ...............................   37
          6.2 Conformance .........................................   39
          6.3 Protocol Correctness ................................   42
          6.3.1 Clock Monotonicity Mechanism ......................   43
          6.3.2 Data Integrity Mechanism ..........................   43
          6.3.3 Data Origin Authentication Mechanism ..............   44
          6.3.4 Restricted Administration Mechanism ...............   44
          6.3.5 Message Timeliness Mechanism ......................   45
          6.3.6 Selective Clock Acceleration Mechanism ............   46
          6.3.7 Confidentiality Mechanism .........................   47
          7 Acknowledgements ......................................   48
          8 References ............................................   49
          9 Authors' Addresses ....................................   51

1. Introduction ✨

okay so a network management system has a few moving parts 🧚. You've got several (potentially many!) nodes, and each one has a processing entity called an agent that can get to its management instrumentation. Then there's at least one management station, plus a management protocol that carries management information between the agents and the stations. All of this runs under an administrative framework that sets both the authentication and the authorization policies 👑

Management stations run management applications that monitor and control network elements. Network elements are things like hosts, routers, terminal servers, and so on, and they get monitored and controlled through access to their management information 💖

In the Administrative Model for SNMPv2 document [1], every SNMPv2 party is, by definition, tied to one authentication protocol and one privacy protocol. That's the whole reason this document exists: Security Protocols for SNMPv2 defines one of each 🦋

The authentication protocol is how SNMPv2 management communications sent by a party can be reliably identified as coming from that party. It also reliably figures out that the message received is the same message that got sent. Iconic 😭

The privacy protocol protects management communications sent to a party from being disclosed. In this memo, the privacy protocol says only authenticated messages may be protected from disclosure 🔒

These protocols are secure alternatives to the so-called "trivial" protocol defined in [2]. Now, read this next part carefully, because it's serious 👀

USE OF THE TRIVIAL PROTOCOL ALONE DOES NOT CONSTITUTE SECURE NETWORK MANAGEMENT. THEREFORE, A NETWORK MANAGEMENT SYSTEM THAT IMPLEMENTS ONLY THE TRIVIAL PROTOCOL IS NOT CONFORMANT TO THIS SPECIFICATION.

The Digest Authentication Protocol is described in Section 3 💅. It gives you a data integrity service by sending a message digest with each SNMPv2 message. The originator computes the digest, and the recipient verifies it. Data origin authentication is handled by prefixing the message with a secret value that only the originator and recipient know, before the digest gets computed. So data integrity is supported explicitly, and data origin authentication is supported implicitly through the digest verification. The way that all fits together is so clean 🧩

The Symmetric Privacy Protocol is described in Section 4 🔐. It keeps messages from being disclosed by encrypting their contents with a secret cryptographic key that only the originator and recipient know. The extra functionality this protocol gives you is assumed to be worth its extra computational cost 🫶

The Digest Authentication Protocol depends on loosely synchronized clocks between the originator and recipient of a message. The protocol spec doesn't make any assumptions about how those clocks get synchronized. Section 5.3 shows one strategy that's especially suited to SNMP network management ⏰

Both protocols in this document need the originator and the recipient of a message to share secret information. The protocol specifications assume those secrets already exist. Picking the secrets and distributing them securely to the right parties can be done in a variety of ways. Section 5.4 shows one such strategy that's especially suited to SNMP network management 🗝️

1.1. A Note on Terminology 📖

For the sake of explanation, the original Internet-standard Network Management Framework, described in RFCs 1155, 1157, and 1212, is called the SNMP version 1 framework (SNMPv1). The current framework is called the SNMP version 2 framework (SNMPv2) 🍓

1.2. Threats 💀

Several of the classic threats to network protocols apply to the network management problem, so they would apply to any SNMPv2 security protocol too. Other threats don't apply to network management at all. This section covers the principal threats, the secondary threats, and the threats that matter less 🙈

The principal threats that any SNMPv2 security protocol should protect against are:

Modification of Information

The SNMPv2 protocol gives management stations a way to interrogate and manipulate the values of objects in a managed agent. The modification threat is the danger that some party alters in-transit messages generated by an authorized party so that unauthorized management operations happen, including falsifying the value of an object. Yikes 😤

Masquerade

The SNMPv2 administrative model includes an access control model, and access control depends on knowing where a message came from. The masquerade threat is the danger that a party tries management operations it isn't authorized for by pretending to be another party that does have the right authorizations 🎭

Two secondary threats are also identified. The security protocols defined in this memo do protect against them:

Message Stream Modification

The SNMPv2 protocol runs over a connectionless transport service, which can operate over any subnetwork service. Messages can get re-ordered, delayed, or replayed through the normal operation of many subnetwork services. The message stream modification threat is the danger that messages get maliciously re-ordered, delayed, or replayed beyond what a subnetwork service would normally cause, in order to carry out unauthorized management operations 🌀

Disclosure

The disclosure threat is the danger of eavesdropping on the exchanges between managed agents and a management station. Protecting against this threat is mandatory when SNMPv2 is used to create new SNMPv2 parties [1] that later secure operation might be based on. Protecting against the disclosure threat may also 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 protect against:

Denial of Service

An SNMPv2 security protocol need not try to address the broad range of attacks that deny service to authorized parties. Honestly, denial-of-service attacks often look exactly like the network failures any viable network management protocol has to deal with as a matter of course 🫠

Okay so the traffic analysis thing is the lowkey plot twist 🕵️ A SNMPv2 security protocol need not try to stop traffic analysis attacks 🙈 Like, a lot of traffic patterns are super predictable. Agents often get managed on a regular schedule by a pretty small group of management stations, so protecting against traffic analysis doesn't really buy you a big advantage 💅

1.3. Goals and Constraints 🎯

After all that threat drama, here's what a SNMPv2 security protocol is actually going for ✨

  1. The protocol SHOULD provide for verification that each received SNMPv2 message has not been modified during its transmission through the network in such a way that an unauthorized management operation might result. 🛡️
  2. The protocol SHOULD provide for verification of the identity of the originator of each received SNMPv2 message. 🪪
  3. The protocol SHOULD provide that the apparent time of generation for each received SNMPv2 message is recent. ⏰
  4. The protocol SHOULD provide, when necessary, that the contents of each received SNMPv2 message are protected from disclosure. 🤫

Principal goal aside, the design is also shaped by these constraints, and they're giving realism 🌸

  1. When the requirements of effective management in times of network stress are inconsistent with those of security, the former are preferred. 🌪️
  2. The security protocol and its underlying security mechanisms SHOULD NOT depend upon the ready availability of other network services (e.g., Network Time Protocol (NTP) or secret/key management protocols). 🙅‍♀️
  3. A security mechanism SHOULD entail no changes to the basic SNMP network management philosophy. 🧘‍♀️

1.4. Security Services 🔐

These are the security services a SNMPv2 security protocol needs to hit its goals, and they're the backbone of the whole vibe 🦋

Data Integrity is the property that data has not been altered or destroyed in an unauthorized manner, and that data sequences haven't been changed to a greater extent than could happen non-maliciously. 💖

Data Origin Authentication is the property that the claimed origin of received data is corroborated. 🪞

Data Confidentiality is the property that information is not made available or disclosed to unauthorized individuals, entities, or processes. 🤐

The protocols in this memo need both data integrity and data origin authentication at all times, no exceptions 💅 You can't get data integrity without data origin authentication, and you can't get data origin authentication without data integrity. They're literally a package deal 🎀

And there's no data confidentiality without both data integrity and data origin authentication already in place 🔒

1.5. Mechanisms ⚙️

The security protocols in this memo use a few different kinds of mechanisms to make those goals and services real ✨

  • In support of data integrity, a message digest algorithm is REQUIRED. A digest is calculated over an appropriate portion of a SNMPv2 message and included as part of the message sent to the recipient. 🧾
  • In support of data origin authentication and data integrity, the portion of a SNMPv2 message that is digested is first prefixed with a secret value shared by the originator of that message and its intended recipient. 🤝
  • To protect against the threat of message delay or replay (to an extent greater than can occur through normal operation), a timestamp value is included in each message generated. A recipient evaluates the timestamp to determine if the message is recent. This protection against the threat of message delay or replay does not imply nor provide any protection against unauthorized deletion or suppression of messages. Other mechanisms defined independently of the security protocol can also be used to detect message replay (e.g., the request-id [2]), or for set operations, the re-ordering, replay, deletion, or suppression of messages (e.g., the MIB variable snmpSetSerialNo [14]). ⏳
  • In support of data confidentiality, a symmetric encryption algorithm is REQUIRED. An appropriate portion of the message is encrypted prior to being transmitted to its recipient. 🔐

The security protocols in this memo are defined independently of the particular choice of message digest and encryption algorithm, mainly because there's no suitable metric for evaluating how secure particular algorithm choices are 🤷‍♀️ However, for completeness and to guarantee interoperability, Sections 1.5.1 and 1.5.2 specify particular choices that are considered acceptably secure as of this writing. In the future, this memo MAY be updated by publishing a memo that specifies substitute or alternate algorithms, i.e., a replacement for or addition to the sections below. 🔄

1.5.1. Message Digest Algorithm 🌈

For data integrity, the MD5 [3] message digest algorithm is chosen. A 128-bit digest is calculated over the designated portion of a SNMPv2 message and included as part of the message sent to the recipient. 💜

An appendix of [3] has a C Programming Language implementation of the algorithm. It was written with portability as the main goal. Implementors MAY wish to optimize the implementation for their own hardware and software platforms. 🛠️

Using this algorithm with the Digest Authentication Protocol (see Section 3) is identified by the ASN.1 object identifier value v2md5AuthProtocol, defined in [4]. (Fun fact: this protocol is a modified version of the md5AuthProtocol protocol defined in RFC 1352 🧚)

For any SNMPv2 party whose authentication protocol is v2md5AuthProtocol, the size of its private authentication key is 16 octets. 🔑

Within an authenticated management communication generated by such a party, the size of the authDigest component of that communication (see Section 3) is 16 octets. 📏

1.5.2. Symmetric Encryption Algorithm 🎀

For data confidentiality, the Data Encryption Standard (DES) in the Cipher Block Chaining mode of operation is chosen. The designated portion of a SNMPv2 message is encrypted and included as part of the message sent to the recipient. 🍓

Two organizations have published DES specifications: the National Institute of Standards and Technology (NIST) [5] and the American National Standards Institute [6]. Each definition has a companion Modes of Operation specification (see [7] and [8], respectively) 📚

NIST has published three more 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 validation test suite for the DES [10]. It's designed to test all aspects of the DES and is useful for pinpointing specific problems. 🔍
  • There's a maintenance test for the DES [11]. It 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. 🔄

Using this algorithm with the Symmetric Privacy Protocol (see Section 4) is identified by the ASN.1 object identifier value desPrivProtocol, defined in [4]. 🪄

For any SNMPv2 party whose privacy protocol is desPrivProtocol, the size of the private 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 is a 56-bit quantity used directly by the algorithm, plus 8 parity bits arranged so that one parity bit is the least significant bit of each octet. The setting of the parity bits is ignored. 🙃

The length of the octet sequence to be encrypted by the DES MUST be an integral multiple of 8. When encrypting, the data SHOULD be padded at the end as necessary, and the actual pad value is insignificant 🫶

If the length of the octet sequence to be decrypted is not an integral multiple of 8 octets, the processing of the octet sequence SHOULD be halted and an appropriate exception noted. Upon decrypting, the padding SHOULD be ignored. 💀

2. SNMPv2 Party ✨

okay so, recall from [1] that a SNMPv2 party is a conceptual, virtual execution context 🔮 whose operation is restricted (for security or other purposes) to an administratively defined subset of all possible operations of a particular SNMPv2 entity. a SNMPv2 entity is the actual process doing the network management work by generating and/or responding to SNMPv2 protocol messages in the manner specified in [12] 🫶. architecturally, every SNMPv2 entity keeps a local database of all the SNMPv2 parties it knows about. main character energy 💅

a SNMPv2 party may be represented by an ASN.1 value with the following syntax:

     SnmpParty ::= SEQUENCE {
       partyIdentity
          OBJECT IDENTIFIER,
       partyTDomain
          OBJECT IDENTIFIER,
       partyTAddress
          OCTET STRING,
       partyMaxMessageSize
          INTEGER,
       partyAuthProtocol
          OBJECT IDENTIFIER,
       partyAuthClock
          INTEGER,
       partyAuthPrivate
          OCTET STRING,
       partyAuthPublic
          OCTET STRING,
       partyAuthLifetime
          INTEGER,
       partyPrivProtocol
          OBJECT IDENTIFIER,
       partyPrivPrivate
          OCTET STRING,
       partyPrivPublic
          OCTET STRING
     }

for each SnmpParty value that represents a SNMPv2 party, the generic significance of each of its components is defined in [1] 📖. for each SNMPv2 party that supports generating messages using the Digest Authentication Protocol, some components get extra special significance 🌸:

  • its partyAuthProtocol component is called the authentication protocol 🔐 and identifies a combo of the Digest Authentication Protocol with a particular digest algorithm (such as the one defined in Section 1.5.1). this combined mechanism is used to authenticate the origin and integrity of all messages generated by the party.
  • its partyAuthClock component is called the authentication clock ⏰ and represents a notion of the current time that is specific to the party.
  • its partyAuthPrivate component is called the private authentication key 🗝️ and represents any secret value needed to support the Digest Authentication Protocol and associated digest algorithm.
  • its partyAuthPublic component is called the public authentication key 🌤️ and represents any public value that may be needed to support the authentication protocol. this component is not significant except as suggested in Section 5.4.
  • its partyAuthLifetime component is called the lifetime ⌛ and represents an administrative upper bound on acceptable delivery delay for protocol messages generated by the party.

for each SNMPv2 party that supports receiving messages via the Symmetric Privacy Protocol, some components get extra special significance too 🎀:

  • its partyPrivProtocol component is called the privacy protocol 🛡️ and identifies a combo of the Symmetric Privacy Protocol with a particular encryption algorithm (such as the one defined in Section 1.5.2). this combined mechanism is used to protect from disclosure all protocol messages received by the party.
  • its partyPrivPrivate component is called the private privacy key 🤫 and represents any secret value needed to support the Symmetric Privacy Protocol and associated encryption algorithm.
  • its partyPrivPublic component is called the public privacy key 🌷 and represents any public value that may be needed to support the privacy protocol. this component is not significant except as suggested in Section 5.4.

3. Digest Authentication Protocol 🦋

this section describes the Digest Authentication Protocol 💖. it gives you both verification of the integrity of a received message (aka the message you got is the message that was sent) and verification of the origin of a message (aka the reliable identification of who sent it) 🕵️‍♀️. the integrity is protected by computing a digest over an appropriate portion of a message. the digest is computed by the originator, transmitted with the message, and verified by the recipient 📬.

a secret value known only to the originator and recipient gets prefixed to the message before the digest computation 🤐. so the origin of the message is known implicitly once the digest checks out. iconic 👑

a requirement for parties using this Digest Authentication Protocol is that they SHALL NOT originate messages for transmission to any destination party that doesn't also use this Digest Authentication Protocol 🚫. this restriction keeps out undesirable side effects of communication between a party that uses these security protocols and a party that doesn't 🙅‍♀️. not me being so responsible 🥹

recall from [1] that a SNMPv2 management communication is represented by an ASN.1 value with the following syntax:

     SnmpMgmtCom ::= [2] IMPLICIT SEQUENCE {
       dstParty
          OBJECT IDENTIFIER,
       srcParty
          OBJECT IDENTIFIER,
       context
          OBJECT IDENTIFIER,
       pdu
          PDUs
     }

for each SnmpMgmtCom value that represents a SNMPv2 management communication, the following statements are true 🧾:

  • its dstParty component is called the destination and identifies the SNMPv2 party the communication is directed to.
  • its srcParty component is called the source and identifies the SNMPv2 party the communication is originated from.
  • its context component identifies the SNMPv2 context containing the management information referenced by the communication.
  • its pdu component has the form and significance attributed to it in [12].

recall from [1] that a SNMPv2 authenticated management communication is represented by an ASN.1 value with the following syntax:

     SnmpAuthMsg ::= [1] IMPLICIT SEQUENCE {
       authInfo
          ANY, - defined by authentication protocol
       authData
          SnmpMgmtCom
     }

for each SnmpAuthMsg value that represents a SNMPv2 authenticated management communication, the following statements are true 🌈:

  • its authInfo component is called the authentication information and represents information required to support the authentication protocol used by both the SNMPv2 party originating the message and the SNMPv2 party receiving it. the detailed significance of the authentication information is specific to the authentication protocol in use. it has no effect on the application semantics of the communication other than its use by the authentication protocol in deciding whether the communication is authentic or not.
  • its authData component is called the authentication data and represents a SNMPv2 management communication.

to support the Digest Authentication Protocol, an authInfo component is of type AuthInformation:

     AuthInformation ::= [2] IMPLICIT SEQUENCE {
       authDigest
          OCTET STRING,
       authDstTimestamp
          UInteger32,
       authSrcTimestamp
          UInteger32
     }

for each AuthInformation value that represents authentication information, the following statements are true 🍓:

  • its authDigest component is called the authentication digest and represents the digest computed over an appropriate portion of the message, where the message is temporarily prefixed with a secret value for the purposes of computing the digest.
  • its authSrcTimestamp component is called the authentication timestamp and represents the time the message was generated according to the partyAuthClock of the SNMPv2 party that originated it. note that the granularity of the authentication timestamp is 1 second ⏱️.
  • its authDstTimestamp component is called the authentication timestamp and represents the time the message was generated according to the partyAuthClock of the SNMPv2 party that is going to receive it. note that the granularity of the authentication timestamp is 1 second ⏱️.

3.1. Generating a Message 💌

this section describes the behavior of a SNMPv2 entity when it acts as a SNMPv2 party whose authentication protocol is administratively specified as the Digest Authentication Protocol 🧚. the way a SNMPv2 entity transmits protocol messages is defined generically in [1], so only the parts specific to the Digest Authentication Protocol are described below. in particular, this section describes how a SNMPv2 management communication gets encapsulated into a SNMPv2 authenticated management communication 🎁.

according to Section 3.1 of [1], a SnmpAuthMsg value is constructed during Step 3 of generic processing. specifically, the authInfo component is constructed according to the authentication protocol identified for the SNMPv2 party originating the message. when the relevant authentication protocol is the Digest Authentication Protocol, the procedure a SNMPv2 entity follows whenever a management communication is to be transmitted by a SNMPv2 party goes like this ✨:

  1. the local database is consulted to determine the authentication clock and private authentication key (extracted, for example, according to the conventions defined in Section 1.5.1) of the SNMPv2 party originating the message. the local database is also consulted to determine the authentication clock of the receiving SNMPv2 party. 🫶

(2) The authSrcTimestamp component gets the retrieved authentication clock value of the message's source 🕰️ The authDstTimestamp component gets the retrieved authentication clock value of the message's intended recipient 💌

(3) The authentication digest is temporarily set to the private authentication key of the SNMPv2 party that originated the message 🔑 The SnmpAuthMsg value is serialized according to the conventions of [13] and [12]. A digest is then computed over the octet sequence representing that serialized value, using for example the algorithm specified in Section 1.5.1 ✨ Finally, the authDigest component is set to the computed digest value 💅

As set forth in [1], the SnmpAuthMsg value is then encapsulated according to the appropriate privacy protocol into a SnmpPrivMsg value 🎁 That value is serialized and transmitted to the receiving SNMPv2 party 🚀

3.2. Receiving a Message 🎀

This section describes what a SNMPv2 entity does when it receives a protocol message from a SNMPv2 party whose authentication protocol is administratively specified as the Digest Authentication Protocol 👀 The generic receiving behavior of a SNMPv2 entity is defined in [1], so this section only covers the parts that are specific to the Digest Authentication Protocol 🧠

According to Section 3.2 of [1], a SnmpAuthMsg value is evaluated during Step 9 of generic processing. To be specific, it is evaluated according to the authentication protocol identified for the SNMPv2 party that originated the message 💖 When the relevant authentication protocol is the Digest Authentication Protocol, here's what a SNMPv2 entity does every time a management communication is received by a SNMPv2 party 📬

(1) If the ASN.1 type of the authInfo component is not AuthInformation, the message is evaluated as unauthentic and the snmpStatsBadAuths counter [14] is incremented 🙅‍♀️ Otherwise, the authSrcTimestamp, authDstTimestamp, and authDigest components are extracted from the SnmpAuthMsg value 🔍

(2) The local database is consulted to find the authentication clock, the private authentication key (extracted for example according to the conventions defined in Section 1.5.1), and the lifetime of the SNMPv2 party that originated the message 📚

(3) If the authSrcTimestamp component plus the lifetime is less than the authentication clock, the message is evaluated as unauthentic and the snmpStatsNotInLifetimes counter [14] is incremented ⏰ bye bye, too old 💀

(4) The authDigest component is extracted and temporarily recorded 📝

(5) A new SnmpAuthMsg value is constructed. Its authDigest component is set to the private authentication key, and its other components are set to the values of the matching components in the received SnmpAuthMsg value 🧩 This new SnmpAuthMsg value is serialized according to the conventions of [13] and [12]. A digest is then computed over the octet sequence representing that serialized value, using for example the algorithm specified in Section 1.5.1 🔐

NOTE Serialization rules are unambiguous but may not be unique, so great care must be taken when reconstructing the serialized value before computing the digest 🙈 Implementations may find it useful to keep a copy of the original serialized value and then simply modify the octets that directly correspond to the placement of the authDigest component, rather than re-applying the serialization algorithm to the new SnmpAuthMsg value 🌸

(6) If the computed digest value is not equal to the digest value temporarily recorded in step 4 above, the message is evaluated as unauthentic and the snmpStatsWrongDigestValues counter [14] is incremented 😭

(7) The message is evaluated as authentic 🫶 ✨

(8) The local database is consulted for the access privileges that the local access policy permits to the originating SNMPv2 party with respect to the receiving SNMPv2 party 🗝️ If any level of access is permitted, then:

  • the authentication clock value locally recorded for the originating SNMPv2 party is advanced to the authSrcTimestamp value, if this latter exceeds the recorded value; and,
  • the authentication clock value locally recorded for the receiving SNMPv2 party is advanced to the authDstTimestamp value, if this latter exceeds the recorded value.

(Note that this step is conceptually independent from Steps 15-17 of Section 3.2 in [1] 🧚)

If the SnmpAuthMsg value is evaluated as unauthentic, an authentication failure is noted and the received message is discarded without further processing 🗑️ Otherwise, processing of the received message continues as specified in [1] 🌈

4. Symmetric Privacy Protocol 🔒

This section describes the Symmetric Privacy Protocol 💜 It provides protection from disclosure for a received message, because an appropriate portion of the message is encrypted according to a secret key that only the originator and recipient of the message know 🤫

This protocol assumes that the underlying mechanism is a symmetric encryption algorithm 🍓 On top of that, the message to be encrypted must be protected according to the conventions of the Digest Authentication Protocol 🛡️

Recall from [1] that a SNMPv2 private management communication is represented by an ASN.1 value with the following syntax:

     SnmpPrivMsg ::= [1] IMPLICIT SEQUENCE {
       privDst
          OBJECT IDENTIFIER,
       privData
          [1] IMPLICIT OCTET STRING
     }

For each SnmpPrivMsg value that represents a SNMPv2 private management communication, the following statements are true:

  • Its privDst component is called the privacy destination, and it identifies the SNMPv2 party that the communication is directed to 📍
  • Its privData component is called the privacy data. It represents the (possibly encrypted) serialization, according to the conventions of [13] and [12], of a SNMPv2 authenticated management communication 🎀

4.1. Generating a Message 💌

This section describes what a SNMPv2 entity does when it communicates with a SNMPv2 party whose privacy protocol is administratively specified as the Symmetric Privacy Protocol 🦋 The generic transmitting behavior is defined in [1], so this section only covers the parts specific to the Symmetric Privacy Protocol 🧁 In particular, it describes how a SNMPv2 authenticated management communication gets encapsulated into a SNMPv2 private management communication 🎁

According to Section 3.1 of [1], a SnmpPrivMsg value is constructed during Step 5 of generic processing. More precisely, its privData component is constructed according to the privacy protocol identified for the SNMPv2 party receiving the message 💅 When the relevant privacy protocol is the Symmetric Privacy Protocol, here's the procedure a SNMPv2 entity follows every time a management communication is to be transmitted by a SNMPv2 party 👑

(1) If the SnmpAuthMsg value is not authenticated according to the conventions of the Digest Authentication Protocol, the generation of the private management communication fails according to a local procedure, without any further processing 🚫

(2) The local database is consulted to determine the private privacy key of the SNMPv2 party receiving the message (represented, for example, according to the conventions defined in Section 1.5.2) 🔑

(3) The SnmpAuthMsg value is serialized according to the conventions of [13] and [12] 🧩

(4) The octet sequence representing the serialized SnmpAuthMsg value is encrypted using, for example, the algorithm specified in Section 1.5.2 and the extracted private privacy key 🔐

(5) The privData component is set to the encrypted value 💖

As set forth in [1], the SnmpPrivMsg value is then serialized and transmitted to the receiving SNMPv2 party 🚀

4.2. Receiving a Message 📥

This section describes what a SNMPv2 entity does when it acts as a SNMPv2 party whose privacy protocol is administratively specified as the Symmetric Privacy Protocol 🌷 The generic receiving behavior is defined in [1], so only the parts specific to the Symmetric Privacy Protocol are described below 🧚‍♀️

According to Section 3.2 of [1], the privData component of a received SnmpPrivMsg value is evaluated during Step 4 of generic processing. Specifically, it is evaluated according to the privacy protocol identified for the SNMPv2 party receiving the message 🌈 When the relevant privacy protocol is the Symmetric Privacy Protocol, here's the procedure a SNMPv2 entity follows every time a management communication is received by a SNMPv2 party 📬

(1) The local database is consulted to determine the private privacy key of the SNMPv2 party receiving the message (represented, for example, according to the conventions defined in Section 1.5.2) 🗂️

(2) The contents octets of the privData component are decrypted using, for example, the algorithm specified in Section 1.5.2 and the extracted private privacy key 🔓

Processing of the received message continues as specified in [1] ✨

5. Clock and Secret Distribution 🕰️🔑

The protocols described in Sections 3 and 4 assume that loosely synchronized clocks and shared secret values exist 🤝 Three requirements constrain the strategy used to distribute clock values and secrets, and the first one is:

  • If the value of an authentication clock is decreased, the private authentication key must be changed concurrently. 🚨

When the value of an authentication clock gets decreased, messages that were sent with a timestamp between the clock's value and its new, lower value may be replayed 🙈 Changing the private authentication key takes care of this threat 💀

  • The private authentication key and private privacy key must be known only to the parties that need to know them 🔐

Protecting the secrets from disclosure is critical to the security of these protocols 🚨 Knowledge of the secrets should be as restricted as possible inside an implementation. Even though a few people may know the secrets during a device's initial configuration, the secrets should be changed right after configuration so their actual values are known only to the software 💅 A management station has the extra job of recovering the state of all parties whenever it boots, and it can handle that by recording the secrets on a long-term storage device 📼 Access to that device must be as restricted as is practically possible 🔒

  • There must exist at least one SNMPv2 entity that takes on the role of a responsible management station 👑

This management station is responsible for making sure all authentication clocks are synchronized and for changing the secret values when necessary ⏰ More than one management station can share this job, but their coordination is essential to the secure management of the network 🫶 How multiple management stations make sure that no more than one of them tries to synchronize the clocks or update the secrets at any one time is a local implementation issue 🧩

A responsible management station may either support clock synchronization and secret distribution as separate functions, or combine them into a single functional unit ✨

The first section below specifies the procedures for initially configuring a SNMPv2 entity 🎀 The next two sections describe one strategy for distributing clock values, and one for figuring out a synchronized clock value among SNMPv2 parties that support the Digest Authentication Protocol 🦋 For SNMPv2 parties that support the Symmetric Privacy Protocol, the next section describes a strategy for distributing secret values 🔑 The last section lays out how a SNMPv2 entity recovers from a "crash" 💥

5.1. Initial Configuration 🎀

This section covers the initial configuration of a SNMPv2 entity that supports the Digest Authentication Protocol, or both the Digest Authentication Protocol and the Symmetric Privacy Protocol 🌸

When a network device is first installed, its initial, secure configuration must be done by hand 🙋‍♀️ That means a person has to physically visit the device and enter the initial secret values for at least its first secure SNMPv2 party 🚶‍♀️ This requirement suggests that the person will know the initial secret values 👀

In general, the security of a system gets better as the number of entities that know a secret goes down 📉 Making a person physically visit a device every single time a SNMPv2 party gets configured not only exposes the secrets for no reason, it's also administratively prohibitive 😭 Specifically, when MD5 is used, the initial authentication secret is 128 bits long, and when DES is used, an additional 128 bits are needed, 64 bits each for the key and the initialization vector 🧮 These values will obviously need to be recorded on a medium so they can be carried between a responsible management station and a managed agent 💾 The recommended procedure is to configure a small set of initial SNMPv2 parties for each SNMPv2 entity, where one pair can be used at the start to configure all the other SNMPv2 parties 🧚

There's actually a minimal, useful set of SNMPv2 parties that could be configured between each responsible management station and managed agent ✨ This minimal set includes one of each of the following, for both the responsible management station and the managed agent:

  • a SNMPv2 party for which the authentication protocol and privacy protocol are the values noAuth and noPriv, respectively,
  • a SNMPv2 party for which the authentication protocol identifies the mechanism defined in Section 1.5.1 and its privacy protocol is the value noPriv, and
  • a SNMPv2 party for which the authentication protocol and privacy protocol identify the mechanisms defined in Section 1.5.1 and Section 1.5.2, respectively.

The last of these SNMPv2 parties, in both the responsible management station and the managed agent, could be used to create all the other SNMPv2 parties 🫧

Configuring one pair of SNMPv2 parties to configure all the other parties has the advantage of exposing only one pair of secrets: the secrets used to configure the minimal, useful set identified above 🥰 To keep that exposure small, the responsible management station should change these values as its very first operation once the initial configuration is done 🔄 That way, the secrets are known only to the peers that need them in order to communicate 🤝

The Management Information Base (MIB) document [4] that supports these security protocols specifies 6 initial party identities and initial values, which, by convention, are assigned to the parties and their associated parameters 📋

These 6 initial parties are required to exist as part of the configuration of implementations when they're first installed, with one exception: implementations that don't provide support for a privacy protocol only need the 4 initial parties whose privacy protocol is noPriv 🎯 When installing a managed agent, these parties need to be configured with their initial secrets, etc., both in the responsible management station and in the new agent 🛠️

If the responsible management station is configured first, it can generate the initial secrets and hand them to a person, on a suitable medium, for distribution to the managed agent 📦 The following sequence of steps describes the initial configuration of a managed agent and its responsible management station 📝

  1. Determine the initial values for each of the attributes of the SNMPv2 party to be configured. Some of these values may be computed by the responsible management station, some may be specified in the MIB document, and some may be administratively determined 🧠
  2. Configure the parties in the responsible management station according to the set of initial values. If the management station is computing some initial values to be entered into the agent, an appropriate medium must be present to record the values 💿
  3. Configure the parties in the managed agent according to the set of initial values 🤖
  4. The responsible management station must synchronize the authentication clock values for each party it shares with each managed agent. Section 5.3 specifies one strategy by which this could be accomplished ⏱️
  5. The responsible management station should change the secret values that were configured manually, so the actual values are known only to the peers that need them in order to communicate 🔐 To do this, the management station generates new secrets for each party to be reconfigured, and distributes the updates using any strategy that protects the new values from disclosure. Using a SNMPv2 set operation acting on the managed objects defined in [4] is one such strategy 🎁 After receiving positive acknowledgement that the new values have been distributed, the management station should update its local database with the new values ✅
If the managed agent doesn't support a protocol that protects messages from disclosure, e.g., the Symmetric Privacy Protocol (see section 5.4), then distributing new secrets after the compromise of existing secrets is not possible 😱 In that case, the new secrets can only be distributed by physically visiting the device 🚗

If there are other SNMPv2 protocol entities that need to know the secrets, the responsible management station must distribute the information once the initial configuration is complete 📣 The considerations mentioned above about protecting secrets from disclosure also apply in this case 🛡️

5.2. Clock Distribution ⏰

A responsible management station must make sure the authentication clock value for each SNMPv2 party it's responsible for

  • is loosely synchronized among all the local databases in which it appears,
  • is reset, as indicated below, upon reaching its maximal value, and
  • is non-decreasing, except as indicated below.

The skew among the clock values must be accounted for in the lifetime value, in addition to the expected communication delivery delay 🕰️

A skewed authentication clock may be detected in a number of ways, including knowing how accurate the system clock is, unauthenticated queries of the party database, and recognizing authentication failures originating from the party 🔍

Whenever clock skew is detected, and whenever the SNMPv2 entities at both the responsible management station and the relevant managed agent support an appropriate privacy protocol (e.g., the Symmetric Privacy Protocol), a straightforward strategy for correcting clock skew is to alter the authentication clock and private key for the relevant SNMPv2 party at the same time 💖 If the request to alter the key and clock for a particular party comes from that same party, then, before transmitting that request, the local notion of the authentication clock is artificially advanced so the request is accepted as authentic 🫶✨

More generally, though, an authentication clock value doesn't need to be protected from disclosure. So a managed agent doesn't have to support a privacy protocol for a responsible management station to correct skewed clock values 🫶 The general procedure for fixing clock skew is in Section 5.3, so keep that in your back pocket ✨

Now here's the other big one. Every SNMPv2 entity has to handle an authentication clock that's getting close to its maximal value, and it has to do it correctly 😤 If the authentication clock for a particular SNMPv2 party ever reaches the maximal time value, the clock must halt right there 🛑 (Heads up: the value you actually care about might be the maximum less lifetime 👀 When a message is authenticated, its authentication timestamp gets lifetime added to it, and that sum is compared to the authentication clock. A SNMPv2 entity must guarantee that the sum is never greater than the maximal time value.) Once the clock is stuck like this, the only authenticated request a management station should generate for that party is one that changes at least its authentication clock and its private authentication key 🔐 To reset those values, the responsible management station may set the authentication timestamp in the message to the maximal time value.

Last rule, and it's a big one: the value of the authentication clock for a particular SNMPv2 party must never be changed so that the new value is less than the old one 🚫⏪ The only exception is if its private authentication key gets changed at the same time.

5.3. Clock Synchronization 🕰️

Unless the secrets are changed at the same time, the correct way to synchronize clocks is to advance the slower clock until it matches the faster one 🏃‍♀️ Let's say party agentParty is realized by the SNMPv2 entity in a managed agent, and party mgrParty is realized by the SNMPv2 entity in the matching responsible management station. For any pair of parties, there are four possible clock conditions that might need fixing:

  1. The management station's notion of the value of the authentication clock for agentParty exceeds the agent's notion.
  2. The management station's notion of the value of the authentication clock for mgrParty exceeds the agent's notion.
  3. The agent's notion of the value of the authentication clock for agentParty exceeds the management station's notion.
  4. The agent's notion of the value of the authentication clock for mgrParty exceeds the management station's notion.

The selective clock acceleration mechanism built into the protocol fixes conditions 1, 2 and 3 automatically as part of normal processing of an authentic message ⚡ That means the clock adjustment procedure below doesn't cover those cases at all. Instead, the following steps explain how the clocks can be synchronized when condition 4 shows up 👇

  1. The responsible management station saves its existing notion of the authentication clock for the party mgrParty.
  2. The responsible management station retrieves the authentication clock value for mgrParty from the agent. This retrieval must be an unauthenticated request, since the management station doesn't know yet whether the clocks are synchronized 🤷‍♀️ If the request fails, the clocks can't be synchronized, and the clock adjustment procedure is aborted without any further processing.
  3. If the notion of the authentication clock for mgrParty that was just retrieved from the agent exceeds the management station's notion, then condition 4 is manifest, and the responsible management station advances its notion of the authentication clock for mgrParty to match the agent's notion 🎉
  4. The responsible management station retrieves the authentication clock value for mgrParty from the agent. This retrieval must be an authenticated request, so the management station can verify that the clock value is properly synchronized 🔍 If this authenticated query fails, the management station restores its previously saved notion of the clock value, and the clock adjustment procedure is aborted without any further processing. Otherwise, clock synchronization has been successfully realized 💅

Administrative advancement of a clock like this doesn't introduce any new vulnerabilities, since the value of the clock is supposed to increase as time passes ⏳ There's one operational problem to watch out for, though: authentic management operations that were authenticated with an earlier value of the relevant party's clock might get rejected 😬 A management station can avoid this by holding off on generating management traffic between the relevant parties while this clock adjustment procedure is in progress.

5.4. Secret Distribution 🔐

This section describes one strategy that a SNMPv2 entity can use to change the secrets for a particular SNMPv2 party, as long as it supports both the Digest Authentication Protocol and the Symmetric Privacy Protocol 💖

How often the secrets of a SNMPv2 party should be changed is a local administrative decision 🗓️ That said, the more often a secret gets used, the more often it should be changed. At a minimum, the secrets must be changed whenever the associated authentication clock approaches its maximal value (see Section 6). Also note that, because of both administrative and automatic advances of the authentication clock described in this memo, the authentication clock for a SNMPv2 party may well approach its maximal value sooner than you'd expect 😳

The following steps show how a responsible management station changes a secret value (that is, the private authentication key or the private privacy key) for a particular SNMPv2 party. There are two cases 👯‍♀️

First, setting the initial secret for a new party:

  1. The responsible management station generates a new secret value.
  2. The responsible management station encapsulates a SNMPv2 setRequest in a SNMPv2 private management communication with at least the following properties.
    • Its source supports the Digest Authentication Protocol and the Symmetric Privacy Protocol.
    • Its destination supports the Symmetric Privacy Protocol and the Digest Authentication Protocol.
  3. The SNMPv2 private management communication is transmitted to its destination.
  4. Upon receiving the request, the recipient processes the message according to [12] and [1].
  5. The recipient encapsulates a SNMPv2 response in a SNMPv2 private management communication with at least the following properties.
    • Its source supports the Digest Authentication Protocol and the Symmetric Privacy Protocol.
    • Its destination supports the Symmetric Privacy Protocol and the Digest Authentication Protocol.
  6. The SNMPv2 private management communication is transmitted to its destination.
  7. Upon receiving the response, the responsible management station updates its local database with the new value 📝

Second, modifying the current secret of an existing party:

  1. The responsible management station generates a new secret value.
  2. The responsible management station encapsulates a SNMPv2 setRequest in a SNMPv2 management communication with at least the following properties.
    • Its source and destination supports the Digest Authentication Protocol.
  3. The SNMPv2 private management communication is transmitted to its destination.
  4. Upon receiving the request, the recipient processes the message according to [12] and [1].
  5. The recipient encapsulates a SNMPv2 response in a SNMPv2 management communication with at least the following properties.
    • Its source and destination supports the Digest Authentication Protocol.
  6. The SNMPv2 management communication is transmitted to its destination.
  7. Upon receiving the response, the responsible management station updates its local database with the new value 📝

If the responsible management station doesn't get a response to its request, there are two possible causes 🤔

  • The request may not have been delivered to the destination.
  • The response may not have been delivered to the originator of the request.

To tell these two error conditions apart, a responsible management station could check the destination to see if the change has happened. Unfortunately, since the secret values are unreadable, that isn't directly possible 😭

The recommended strategy for verifying key changes is to set the public value that matches the secret being changed to a recognizable, novel value 🌈 In other words, change the public authentication key value for the relevant party when changing its private authentication key, or change its public privacy key value when changing its private privacy key. That way, the responsible management station can retrieve the public value when no response comes back, and check whether the change actually took place ✨ (This strategy works because the public values aren't used by the protocols defined in this memo. If you use this strategy, then the public values become significant in this context. Of course, protocols that do use the public values can make use of this strategy directly 🧚)

okay so there's one more scenario worth talking about 👀: a SNMPv2 party changing its own secrets 🔐. In this case the destination updates its local database before it builds the response, so the response gets built with the new value ✨. Meanwhile the responsible management station doesn't update its own database until after it gets the response back 🙈. That means the station may receive a response that gets judged as unauthentic, unless it uses the correct secret. The responsible management station may either treat this as a special case, or use an alteration of the relevant public values (as described above) to verify the key change 🧠

Note 📝: between sending the request and getting the response back, the management station must keep track of both the old and new secret values. The delay could be caused by a network failure, so the management station must be prepared to keep both values around for an extended period, even across reboots 💾

5.5. Crash Recovery

This part is all about how SNMPv2 protocol entities need to recover after a system crash or some other service interruption 🛠️

For each SNMPv2 party in the local database of a SNMPv2 entity, its identity, authentication clock, private authentication key, and private privacy key must enjoy non-volatile, incorruptible representations 🔒. If possible, lifetime should also enjoy a non-volatile, incorruptible representation. If that SNMPv2 entity supports other security protocols or algorithms besides the two defined in this memo, then the authentication protocol and the privacy protocol for each party also require non-volatile, incorruptible representation 💅

The authentication clock of a SNMPv2 party is a critical part of the overall security of the protocols 😭. Having a reliable representation of a clock in a SNMPv2 entity is required for overall security ⏰. A reliable clock representation makes sure the clock's value keeps going up monotonically, even across a power loss or other system failure of the local SNMPv2 entity 📈. One example is the battery-powered clock-calendar devices found in some modern systems 🔋. Another example is storing and updating a clock value in non-volatile storage once every U (e.g., 24) hours, then re-initialising that clock value on every reboot as the stored value plus U+1 hours 🧮. It's assumed that management stations always support reliable clock representations, and a human operator adjusting the clock during crash recovery can help with that reliability 🙌

If a managed agent crashes and doesn't reboot in time for its responsible management station to stop its authentication clock from reaching its maximal value, the clock must be halted at its maximal value once it reboots 🛑. The procedures specified in Section 5.3 would then apply 📋

Upon recovery, the attributes of each SNMPv2 party that don't have a non-volatile or reliable representation get initialized like this ✨:

  • If the private authentication key is not the OCTET STRING of zero length, the authentication protocol is set to identify use of the Digest Authentication Protocol in conjunction with the algorithm specified in Section 1.5.1 🔑
  • If the lifetime is not retained, it should be initialized to zero ⏳
  • If the private privacy key is not the OCTET STRING of zero length, the privacy protocol is set to identify use of the Symmetric Privacy Protocol in conjunction with the algorithm specified in Section 1.5.2 🫶

Upon detecting that a managed agent has rebooted, a responsible management station must reset all other party attributes, including the lifetime if it wasn't retained 🔄. To reset the lifetime, the responsible management station should set the authentication timestamp in the message to the sum of the authentication clock and the desired lifetime 🧁. This artificially advances the authentication timestamp so the message is guaranteed to be authentic when the recipient gets it 🦋

6. Security Considerations 🛡️

This section is the security tea ☕️, so pay attention, bestie 😤 It covers the security stuff that matters for the protocols and procedures in this memo. First up are the practices that help keep things secure and running well. Next are the constraints on implementation behaviour that the security of the system depends on. Last, there's an informal rundown of how each mechanism in the protocols helps hit the goals we need 🎯

This section covers the practices that help the mechanisms in this memo stay secure and effective 💖

  • A management station should discard SNMPv2 responses where neither the request-id component nor the represented management information matches any currently outstanding request 🗑️

Sure, it'd be typical for a management station to do this anyway 🙄 but with these security protocols it's a big deal, because messages can get duplicated, whether on purpose or by accident 👀

  • A management station should not interpret an agent's lack of response to an authenticated SNMPv2 management communication as a conclusive sign of agent or network failure 🙅‍♀️

Authentication failure traps can get lost or suppressed because of authentication clock skew or mismatched notions of shared secrets 📉. To help with administering these SNMPv2 parties, or to keep management going during network stress, a management station implementation may provide for arbitrary, artificial advancement of the timestamp, or selection of shared secrets, on locally generated messages 🧰

  • The lifetime value for a SNMPv2 party should be chosen by the local administration to be as small as possible, given the accuracy of the clock devices available, the relevant round-trip communication delays, and how often a responsible management station can verify all clock values ⏱️

A big lifetime makes it easier for someone to maliciously delay SNMPv2 messages 😈. A management station implementation may handle changing network conditions during network stress by effectively increasing the lifetimes of the source and destination parties 🌩️. It does this by artificially advancing its notion of the source party's clock on messages it sends, and by artificially increasing its notion of the source party's lifetime on messages it receives 🪄

  • 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 🚦

SNMPv2 doesn't impose any message ordering. Messages can be received in any order relative to when they were generated, and each one gets processed in the order it was received 🌀. Also, an authenticated message sent to a managed agent stays valid for a period that, under normal circumstances, doesn't exceed lifetime, and it's open to replay during that period 🎭

A management station must cope with the loss and re-ordering of messages caused by anomalies in the network as a matter of course 🧘‍♀️

That said, a managed object, snmpSetSerialNo [14], is specifically defined for use with SNMPv2 set operations 💅. It gives you a way to make sure SNMPv2 messages get processed in a specific order 📋

  • The frequency with which the secrets of a SNMPv2 party should be changed is indirectly related to how often they're used 🔁

Keeping secrets from getting disclosed is critical to the overall security of the protocols 🤫. Frequent use of a secret gives a cryptanalyst a steady stream of data they could use to exploit known or suspected weaknesses in an algorithm 🕵️‍♀️. Changing the secret often gets rid of that risk 🙌

Changing a secret after each use is generally seen as the most secure practice, but it can come with a lot of overhead 😮‍💨

Also, in a local environment the threat of disclosure might be pretty small, so secrets can be changed less often there 🏡. When public data networks are the communication paths, though, more caution is wise ⚠️

  • A management station implementation must support constrained, pairwise sharing of secrets among SNMPv2 entities as its default mode of operation 💕

Because the protocols here use symmetric cryptography, the secrets for a particular SNMPv2 party must be known to every other SNMPv2 party that party might want to talk to 🤝. The more locations where secrets are known and used, the more likely they are to get disclosed, and the bigger the damage would be if they were 💥. Plus, if more than two SNMPv2 protocol entities know a particular secret, data origin can't be reliably authenticated, because there's no way to know for sure which entity in that group sent a particular SNMPv2 message 🫠. So the greatest degree of security comes from setups where each SNMPv2 party's secrets are known to at most two protocol entities 🔐✨

6.2. Conformance

Okay bestie, so if an SNMPv2 entity wants to claim conformance with this memo, it MUST satisfy the following requirements ✨

  1. It MUST implement the noAuth and noPriv protocols, whose object identifiers are defined in [4].
    • noAuth 🫥: this protocol says messages generated by a party using it are not protected as to origin or integrity. It is REQUIRED to ensure that a party's authentication clock is always accessible.
    • noPriv 🙈: this protocol says messages received by a party using it are not protected from disclosure. It is REQUIRED to ensure that a party's authentication clock is always accessible.
  2. It MUST implement the Digest Authentication Protocol in conjunction with the algorithm defined in Section 1.5.1 💖
  3. It MUST include in its local database at least one SNMPv2 party with these parameters set like this 🎀:
    • partyAuthProtocol is set to noAuth, and
    • partyPrivProtocol is set to noPriv.

This party MUST have a MIB view [1] specified that includes at least the authentication clock of all other parties. Alternatively, the authentication clocks of the other parties MAY be partitioned among several similarly configured parties according to a local implementation convention.

  1. For each SNMPv2 party it keeps information about in a local database, an implementation MUST satisfy the following requirements 🔐:
    • (a) It MUST NOT allow a party's parameters to be set to a value inconsistent with its expected syntax. In particular, Section 1.4 specifies constraints for the chosen mechanisms.
    • (b) It MUST, to the maximal extent possible, prohibit read-access to the private authentication key and private encryption key under all circumstances, except as REQUIRED to generate and/or validate SNMPv2 messages with respect to that party.

This prohibition includes prevention of read-access by the entity's human operators. 👀

  • (c) It MUST allow the party's authentication clock to be publicly accessible. The correct operation of the Digest Authentication Protocol requires that it be possible to determine this value at all times, so that skewed authentication clocks can be resynchronized ⏰.
  • (d) It MUST prohibit alterations to its record of the authentication clock for that party independently of alterations to its record of the private authentication key (unless the clock alteration is an advancement).
  • (e) It MUST never allow its record of the authentication clock for that party to be incremented beyond the maximal time value and so "roll-over" to zero 🙅‍♀️.
  • (f) It MUST never increase its record of the lifetime for that party, except as MAY be explicitly authorized (via imperative command or securely represented configuration information) by the responsible network administrator 📋.
  • (g) If the non-volatile, incorruptible representations of a party's parameters (in particular, either the private authentication key or private encryption key) are lost or destroyed, it MUST alter its record of these quantities to random values, so subsequent interaction with that party requires manual redistribution of new secrets and other parameters 💥.
  1. If it selects new value(s) for a party's secret(s), it MUST avoid bad or obvious choices for said secret(s). Choices to be avoided are boundary values (such as all-zeros) and predictable values (such as the same value as previously, or selecting from a predetermined set) 🙄.
  2. It MUST ensure that a received message, for which the originating party uses the Digest Authentication Protocol but the receiving party does not, is always declared to be unauthentic. This MAY be achieved explicitly via an additional step in the procedure for processing a received message, or implicitly by verifying that all local access control policies enforce this requirement 🚫.

6.3. Protocol Correctness 💅

Okay, so the correctness of these SNMPv2 security protocols with respect to the stated goals depends on the following assumptions 🧠:

  1. The chosen message digest algorithm satisfies its design criteria. In particular, it MUST be computationally infeasible to discover two messages that share the same digest value.
  2. It is computationally infeasible to determine the secret used in calculating a digest on the concatenation of the secret and a message, when both the digest and the message are known.
  3. The chosen symmetric encryption algorithm satisfies its design criteria. In particular, it MUST be computationally infeasible to determine the cleartext message from the ciphertext message without knowledge of the key used in the transformation 🔒.
  4. Local notions of a party's authentication clock, while it is associated with a specific private key value, are monotonically non-decreasing (i.e., they never run backwards) in the absence of administrative manipulations ⏳.
  5. The secrets for a particular SNMPv2 party are known only to authorized SNMPv2 protocol entities 🤫.
  6. Local notions of the authentication clock for a particular SNMPv2 party are never altered such that the authentication clock's new value is less than the current value, without also altering the private authentication key.

For each mechanism of the protocol, an informal account of its contribution to the required goals is presented below. Pseudocode fragments are provided where appropriate to exemplify possible implementations, and they are intended to be self-explanatory 🌸.

6.3.1. Clock Monotonicity Mechanism 🕰️

By pairing each sequence of a clock's values with a unique key, the protocols partially realize goal 3. The conjunction of this property with assumption 6 above is sufficient for the claim that, with respect to a specific private key value, all local notions of a party's authentication clock are, in general, non-decreasing with time 📈.

6.3.2. Data Integrity Mechanism 🧩

The protocols require computation of a message digest over the SNMPv2 message, prepended by the secret for the relevant party. By virtue of this mechanism and assumptions 1 and 2, the protocols realize goal 1 🎉.

Normally, including the message digest value with the digested message would not be sufficient to guarantee data integrity, since the digest value can be modified in addition to the message while it is enroute. However, since not all of the digested message is included in the transmission to the destination, it is not possible to substitute both a message and a digest value while enroute to a destination 🙅‍♀️.

Strictly speaking, the specified strategy for data integrity does not detect a SNMPv2 message modification which appends extraneous material to the end of such messages. However, owing to the representation of SNMPv2 messages as ASN.1 values, such modifications cannot, consistent with goal 1, result in unauthorized management operations 🛡️.

The data integrity mechanism specified in this memo protects only against unauthorized modification of individual SNMPv2 messages. A more general data integrity service that affords protection against the threat of message stream modification is not realized by this mechanism. Limited protection against reordering, delay, and duplication of messages within a message stream is provided by other mechanisms of the protocol, though 🌈.

6.3.3. Data Origin Authentication Mechanism 🪪

The data integrity mechanism requires the use of a secret value known only to communicating parties. By virtue of this mechanism and assumptions 1 and 2, the protocols explicitly prevent unauthorized modification of messages. Data origin authentication is implicit if the message digest value can be verified. That is, the protocols realize goal 2 💜.

6.3.4. Restricted Administration Mechanism 🚧

This memo requires that implementations preclude administrative alterations of the authentication clock for a particular party independently from its private authentication key (unless that clock alteration is an advancement). An example of an efficient implementation of this restriction is provided in the pseudocode fragment below. This pseudocode fragment meets the requirements of assumption 6. Observe that the requirement is not for simultaneous alteration, but to preclude independent alteration. This latter requirement is fairly easily realized in a way that is consistent with the defined semantics of the SNMPv2 set operation 🧁.

     Void partySetKey (party, newKeyValue)
     {
         if (party->clockAltered) {
            party->clockAltered = FALSE;
            party->keyAltered = FALSE;
            party->keyInUse = newKeyValue;
            party->clockInUse = party->clockCache;
         }
         else {
            party->keyAltered = TRUE;
            party->keyCache = newKeyValue;
         }
     }

     Void partySetClock (party, newClockValue)
     {
         if (party->keyAltered) {
            party->keyAltered = FALSE;
            party->clockAltered = FALSE;
            party->clockInUse = newClockValue;
            party->keyInUse = party->keyCache;
         }
         else {
            party->clockAltered = TRUE;
            party->clockCache = newClockValue;
         }
     }

6.3.5. Message Timeliness Mechanism ⏱️

The timeliness check is where things get serious, bestie 🕰️✨. If the timestamp on a received message, plus the administratively chosen lifetime, is less than or equal to the local notion of the clock for the originating SNMPv2 party, the message is not delivered 🚫. Here's the check, straight from the source:

if (timestampOfReceivedMsg +
       party->administrativeLifetime <=
       party->localNotionOfClock) {
       msgIsValidated = FALSE;
}

This is how the protocols hit goal 3 🎯. When the local notions of a party's clock are moderately well synchronized, the timeliness mechanism effectively caps how old a validly delivered message can be. So if an attacker grabs every validated message and replays them way later, the delay they can cause stays proportional to the skew among the local notions of the party clock. Small skew, small window. Iconic 💅

6.3.6. Selective Clock Acceleration Mechanism 🚀

The SNMPv2 security protocols say that if either timestamp value for the originating or receiving party on a received, validated message is ahead of the corresponding local notion of that party's clock, the local clock gets pushed forward to match that timestamp ⏩. This mechanism is neither strictly necessary nor sufficient for the security of the protocol 🙈. What it actually does is encourage clock synchronization, which valid message delivery depends on, so it makes the protocol more effective in a management context 🫶.

if (msgIsValidated) {
       if (timestampOfReceivedMsg >
             party->localNotionOfClock) {
             party->localNotionOfClock =
                   timestampOfReceivedMsg;
       }
}

The main effect is that clocks get more closely synchronized when a sender's notion of the clock is further ahead than the receiver's 🌸. In the opposite case, this mechanism does nothing to the local clock, and whether the message is validly delivered depends on the other mechanisms in the protocol 🤷‍♀️.

Running this mechanism doesn't, in general, boost the odds of validated delivery for messages from participants whose clock is behind 😭. So queries from a management station might not get validly delivered, and the station has to respond sensibly, for example with the strategy in section 5.3 🧠. Traps are the more worrying case 💀. If an agent's party clock is behind, its trap messages can have trouble getting delivered, and the agent may not even be able to notice and react to the security failures stopping them. The inherently unreliable nature of traps can get even worse when you try to force validated delivery on them 📉.

6.3.7. Confidentiality Mechanism 🔐

When data confidentiality is required, the protocols require the use of a symmetric encryption algorithm 🗝️. Thanks to this mechanism and assumption 3, the protocols hit goal 4 💜.

7. Acknowledgements 🫶

This document is based, almost entirely, on RFC 1352 📜.

8. References 📚

[1] Galvin, J., and McCloghrie, K., "Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1445, Trusted Information Systems, Hughes LAN Systems, April 1993.

[2] Case, J., Fedor, M., Schoffstall, M., Davin, J., "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] McCloghrie, K., and Galvin, J., "Party MIB for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1447, Hughes LAN Systems, Trusted Information Systems, April 1993.

[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] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1448, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993.

[13] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Transport Mappings for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1449, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993.

[14] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Management Information Base for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1450, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993.

9. Authors' Addresses 💌

James M. Galvin
Trusted Information Systems, Inc.
3060 Washington Road, Route 97
Glenwood, MD 21738

Phone:  +1 301 854-6889
EMail:  galvin@tis.com


Keith McCloghrie
Hughes LAN Systems
1225 Charleston Road
Mountain View, CA  94043
US

Phone: +1 415 966 7934
Email: kzm@hls.com
📦 where this page comes from