RFC 1352

SNMP Security Protocols

📅 published July 1992, from ietf

RFC 1352: SNMP Security Protocols 🎀

okay bestie, this is RFC 1352, and it's all about locking down SNMP (the Simple Network Management Protocol) 🔐✨ It's dated July 1992 and was published by the Network Working Group. The authors are J. Galvin of Trusted Information Systems, Inc., K. McCloghrie of Hughes LAN Systems, Inc., and J. Davin of the MIT Laboratory for Computer Science 💜. It's an IAB standards track protocol, and the title block doesn't list anything it obsoletes or updates, so it's standing on its own 💅

Status of this Memo 📜

so this doc specifies an IAB standards track protocol for the Internet community, and it's literally asking for discussion and suggestions to make it better 🫶 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.    Abstract . . . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.1   Threats  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.2   Goals and Constraints  . . . . . . . . . . . . . . . . . . .   5
   2.3   Security Services  . . . . . . . . . . . . . . . . . . . . .   6
   2.4   Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . .   6
   2.4.1   Message Digest Algorithm . . . . . . . . . . . . . . . . .   7
   2.4.2   Symmetric Encryption Algorithm . . . . . . . . . . . . . .   8
   3.    SNMP Party   . . . . . . . . . . . . . . . . . . . . . . . .   9
   4.    Digest Authentication Protocol . . . . . . . . . . . . . . .  11
   4.1   Generating a Message   . . . . . . . . . . . . . . . . . . .  14
   4.2   Receiving a Message  . . . . . . . . . . . . . . . . . . . .  15
   5.    Symmetric Privacy Protocol . . . . . . . . . . . . . . . . .  16
   5.1   Generating a Message   . . . . . . . . . . . . . . . . . . .  17
   5.2   Receiving a Message  . . . . . . . . . . . . . . . . . . . .  18
   6.    Clock and Secret Distribution  . . . . . . . . . . . . . . .  19
   6.1   Initial Configuration    . . . . . . . . . . . . . . . . . .  20
   6.2   Clock Distribution   . . . . . . . . . . . . . . . . . . . .  22
   6.3   Clock Synchronization  . . . . . . . . . . . . . . . . . . .  24
   6.4   Secret Distribution  . . . . . . . . . . . . . . . . . . . .  26
   6.5   Crash Recovery   . . . . . . . . . . . . . . . . . . . . . .  28
   7.    Security Considerations  . . . . . . . . . . . . . . . . . .  30
   7.1   Recommended Practices  . . . . . . . . . . . . . . . . . . .  30
   7.2   Conformance    . . . . . . . . . . . . . . . . . . . . . . .  33
   7.3   Protocol Correctness . . . . . . . . . . . . . . . . . . . .  34
   7.3.1   Clock Monotonicity Mechanism . . . . . . . . . . . . . . .  35
   7.3.2   Data Integrity Mechanism . . . . . . . . . . . . . . . . .  36
   7.3.3   Data Origin Authentication Mechanism . . . . . . . . . . .  36
   7.3.4   Restricted Administration Mechanism  . . . . . . . . . . .  36
   7.3.5   Ordered Delivery Mechanism   . . . . . . . . . . . . . . .  37
   7.3.6   Message Timeliness Mechanism . . . . . . . . . . . . . . .  38
   7.3.7   Selective Clock Acceleration Mechanism . . . . . . . . . .  38
   7.3.8   Confidentiality Mechanism  . . . . . . . . . . . . . . . .  39
   8.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  39
   9.    References . . . . . . . . . . . . . . . . . . . . . . . . .  40
   10.   Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  41

1. Abstract 🌸

okay so the Simple Network Management Protocol (SNMP) spec [1] lets you protect network management operations with a whole variety of security protocols 🔐 The SNMP administrative model described in [2] gives us a framework for securing SNMP network management 🖼️ and inside that framework, this memo defines protocols that support these three security services:

  • data integrity,
  • data origin authentication, and
  • data confidentiality.

Send comments to the SNMP Security Developers mailing list (snmp-sec-dev@tis.com) 💌

2. Introduction 🧚

in the model from [2], every SNMP party is, by definition, tied to exactly one authentication protocol 🪪 That authentication protocol is how we reliably tell that SNMP management traffic really came from the party that sent it. The one defined in this memo also reliably confirms that the message you received is the exact message that was sent 💯

same deal for privacy: every SNMP party is, by definition, tied to exactly one privacy protocol 🙈 The privacy protocol keeps SNMP management traffic sent to that party from being disclosed. The privacy protocol in this memo says that only authenticated messages may be protected from disclosure 🔒

these protocols are secure alternatives to the so-called "trivial" protocol defined in [1] 💅

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 in Section 4 🧾 It gives you data integrity by sending a message digest with each SNMP message, where the originator computes it and the recipient verifies it. Data origin authentication comes from putting a secret value that only the originator and recipient know in front of the message before the digest is computed. So data integrity is handled explicitly, while data origin authentication is handled implicitly when the digest gets verified 🕵️‍♀️

the Symmetric Privacy Protocol is in Section 5 🔐 It hides messages by encrypting their contents with a secret cryptographic key that only the originator and recipient have. The extra stuff this protocol adds 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 spec makes no assumptions about how those clocks get synchronized. Section 6.3 shows one strategy that's especially suited to what SNMP network management needs 🕰️

both protocols need the originator and recipient of a message to share secret information 🤫 The specs assume those secrets already exist. Picking the secrets and getting them securely to the right parties can be done in a bunch of different ways, and Section 6.4 covers one that fits SNMP network management really well 🗝️

2.1. Threats 😈

a bunch of the classic network protocol threats apply to network management, so they'd apply to any SNMP security protocol too 🕸️ Others don't apply here. This section covers the principal threats, the secondary threats, and the threats that matter less.

the principal threats that any SNMP security protocol should protect against are:

Modification of Information. SNMP lets management stations ask about and change the values of objects on a managed agent 🛠️ The modification threat is when someone alters in-transit messages from an authorized party so they cause unauthorized management operations, like faking the value of an object 🙀

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

two secondary threats are identified too. The security protocols in this memo do protect against these:

Message Stream Modification. SNMP runs on connectionless transport services 🌊 The threat is that messages could be reordered, delayed, or replayed to pull off unauthorized management operations. That can happen because of a malicious attacker or just because of how a subnetwork service naturally works 😬

Disclosure. This is eavesdropping on the exchanges between managed agents and a management station 👀 Protecting against it is mandatory when SNMP is used to administer the private parameters its security is based on. It may also be required by local policy 📋

there are at least two threats that an SNMP security protocol doesn't need to protect against. The security protocols in this memo do not protect against these:

Denial of Service. An SNMP security protocol doesn't need to try to address the huge range of attacks that deny service to authorized parties 🙅 Honestly, lots of these denial-of-service attacks look exactly like ordinary network failures, and any viable network management protocol has to cope with those as a matter of course 🌧️

Traffic Analysis. An SNMP security protocol also doesn't need to address traffic analysis attacks 📊 Lots of traffic patterns are predictable (agents may get managed on a regular basis by a fairly small number of management stations 🗓️), so protecting against traffic analysis wouldn't buy you any significant advantage.

2.2. Goals and Constraints 🎯

based on all that threat talk above, the goals of an SNMP security protocol are listed below ✅

  1. The protocol should provide verification that each received SNMP message wasn't modified during its transmission through the network in a way that could lead to an unauthorized management operation.
  2. The protocol should provide verification of the identity of the originator of each received SNMP message 🪪
  3. The protocol should provide that the apparent time of generation for each received SNMP message is recent ⏱️
  4. The protocol should provide that the apparent time of generation for each received SNMP message is subsequent to that of all previously delivered messages of similar origin 📅
  5. The protocol should provide, when necessary, that the contents of each received SNMP message are protected from disclosure 🔐

besides the main goal of supporting secure network management, the design of any SNMP security protocol is also shaped by these constraints 🧱

  1. When the requirements of effective management during network stress conflict with those of security, the requirements of effective management are preferred 🏆
  2. 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 secret/key management protocols) 🙅‍♀️
  3. A security mechanism should entail no changes to the basic SNMP network management philosophy 🧘

2.3. Security Services 🔐

okay bestie, the security services a SNMP security protocol needs to hit its goals are these three 💅

  • Data Integrity 🛡️ is the property that data and data sequences have not been altered or destroyed in an unauthorized manner. no sneaky edits allowed!
  • Data Origin Authentication 🪪 is the property that the claimed origin of received data is corroborated. basically, you check that the message really came from who it says it came from.
  • Data Confidentiality 🤐 is the property that information is not made available or disclosed to unauthorized individuals, entities, or processes. keep it secret, keep it safe.

The protocols specified in this memo require both data integrity and data origin authentication to be used at all times 🙌 For these protocols, it is not possible to realize data integrity without data origin authentication, nor is it possible to realize data origin authentication without data integrity. they're a total package deal 💜

bestie, integrity and origin authentication always come as a pair. you can't have one without the other 👯

Further, there is no provision for data confidentiality without both data integrity and data origin authentication. so confidentiality is the VIP that needs both of its bodyguards 👑

2.4. Mechanisms 🧰

The security protocols defined in this memo use several types of mechanisms to hit the goals and services described above:

  • In support of data integrity, a message digest algorithm is required. A digest is calculated over an appropriate portion of a SNMP 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 SNMP 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 reordering, a timestamp value is included in each message generated. A recipient evaluates the timestamp to determine if the message is recent, and it uses the timestamp to determine if the message is ordered relative to other messages it has received. In conjunction with other readily available information (e.g., the request-id), the timestamp also indicates whether or not the message is a replay of a previous message. ⏰ But heads up: this protection against reordering implies no protection against unauthorized deletion or suppression of messages. 💀
  • 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 a message digest and encryption algorithm — owing principally to the lack of a suitable metric by which to evaluate the security of particular algorithm choices. However, in the interests of completeness and in order to guarantee interoperability, Sections 2.4.1 and 2.4.2 specify particular choices, which are considered acceptably secure as of this writing. In the future, this memo may be updated by the publication of a memo specifying substitute or alternate choices of algorithms, i.e., a replacement for or addition to the sections below. the algorithm picks can glow up later 🦋

2.4.1. Message Digest Algorithm 🧮

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

An appendix of [3] contains a C Programming Language implementation of the algorithm. This code was written with portability being the principal objective. Implementors may wish to optimize the implementation with respect to the characteristics of their hardware and software platforms. 💻

The use of this algorithm in conjunction with the Digest Authentication Protocol (see Section 4) is identified by the ASN.1 object identifier value md5AuthProtocol, defined in [4].

For any SNMP party for which the authentication protocol is md5AuthProtocol, 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 4) is 16 octets. ✨

2.4.2. Symmetric Encryption Algorithm 🔐

In support of data confidentiality, the use of the Data Encryption Standard (DES) in the Cipher Block Chaining mode of operation is chosen. The designated portion of a SNMP 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 is 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 is a document with guidelines for implementing and using the DES, including functional specifications for the DES and its modes of operation [9].
  • There is 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 is a specification of a maintenance test for the DES [11]. The test utilizes a minimal amount of data and processing to test all components of the DES. It provides 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. 🔄

The use of this algorithm in conjunction with the Symmetric Privacy Protocol (see Section 5) is identified by the ASN.1 object identifier value desPrivProtocol, defined in [4].

For any SNMP party for which the privacy protocol is desPrivProtocol, the size of the private privacy key is 16 octets, of which 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 — 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; 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. 🙅‍♀️

3. SNMP Party 🎉

Recall from [2] that a SNMP 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 SNMP protocol entity. A SNMP protocol entity is an actual process which performs network management operations by generating and/or responding to SNMP protocol messages in the manner specified in [1]. Architecturally, every SNMP protocol entity maintains a local database that represents all SNMP parties known to it. 🗂️

A SNMP party may be represented by an ASN.1 value with the following syntax.

   SnmpParty ::= SEQUENCE {
     partyIdentity
        OBJECT IDENTIFIER,
     partyTDomain
        OBJECT IDENTIFIER,
     partyTAddr
        OCTET STRING,
     partyProxyFor
        OBJECT IDENTIFIER,
     partyMaxMessageSize
        INTEGER,
     partyAuthProtocol
        OBJECT IDENTIFIER,
     partyAuthClock
        INTEGER,
     partyAuthLastMsg
        INTEGER,
     partyAuthNonce
        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 SNMP party, the generic significance of each of its components is defined in [2]. For each SNMP party that supports the generation of messages using the Digest Authentication Protocol, additional, special significance is attributed to certain components of that party's representation: 🔑

  • Its partyAuthProtocol component is called the authentication protocol and identifies a combination of the Digest Authentication Protocol with a particular digest algorithm (such as that defined in Section 2.4.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 partyAuthLastMsg component is called the last-timestamp and represents a notion of time associated with the most recent, authentic protocol message generated by the party.
  • Its partyAuthNonce component is called the nonce and represents a monotonically increasing integer associated with the most recent, authentic protocol message generated by the party. The nonce associated with a particular message distinguishes it among all others transmitted in the same unit time interval.
  • 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 6.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 SNMP party that supports the receipt of messages via the Symmetric Privacy Protocol, additional, special significance is attributed to certain components of that party's representation: 🤫

  • Its partyPrivProtocol component is called the privacy protocol and identifies a combination of the Symmetric Privacy Protocol with a particular encryption algorithm (such as that defined in Section 2.4.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 6.4. 🌈

4. Digest Authentication Protocol ✨

okay bestie, this section is the Digest Authentication Protocol and it is SO good 💅. It checks two things: that the message you received is the message that was sent (integrity 🔒), and that you can reliably tell who sent it (origin 🫶). The originator computes a digest over an appropriate portion of the message, sends it along with the message, and the recipient checks it ✨.

The main trick is a secret value that only the originator and the recipient know. It gets stuck on the front of the message before the digest is computed. So when the digest checks out, the origin is known implicitly. iconic 👑

Recall from [2] that a SNMP management communication is an ASN.1 value with this syntax:

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

For every SnmpMgmtCom value that represents a SNMP management communication, these things are true 🌸:

  • Its dstParty component is called the destination. It tells you which SNMP party the communication is aimed at.
  • Its srcParty component is called the source. It tells you which SNMP party the communication came from.
  • Its pdu component has the form and significance described for it in [1].

Recall from [2] that a SNMP authenticated management communication is an ASN.1 value with this syntax:

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

For every SnmpAuthMsg value that represents a SNMP authenticated management communication, these things are true 🦋:

  • Its authInfo component is called the authentication information. It holds whatever the authentication protocol in use needs, and it's set by the SNMP party that sent the message. What it means depends entirely on that protocol. It doesn't change the application semantics of the communication at all. Its only job is helping the authentication protocol decide whether the communication is authentic or not 🧚.
  • Its authData component is called the authentication data. It carries a SNMP management communication.

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

   AuthInformation ::= [1] IMPLICIT SEQUENCE {
     authTimestamp
        INTEGER (0..2147483647),
     authNonce
        INTEGER (0..2147483647),
     authDigest
        OCTET STRING
   }

For every AuthInformation value that represents authentication information, these things are true 💜:

  • Its authTimestamp component is called the authentication timestamp. It records when the message was generated, going by the partyAuthClock of the SNMP party that sent it. The granularity of the authentication timestamp is 1 second, so keep that in mind ⏰.
  • Its authNonce component is called the authentication nonce. It's a non-negative integer, evaluated according to the authTimestamp value. Transmission frequency isn't capped at the timestamp's 1-second granularity, because the nonce is there to tell apart multiple messages sent with the same authTimestamp value. It's a monotonically increasing sequence number that resets for each new authTimestamp value 🔢.
  • Its authDigest component is called the authentication digest. It's the digest computed over an appropriate portion of the message, where the message is temporarily prefixed with a secret value while the digest is being computed 🔐.

4.1 Generating a Message

this part covers what a SNMP protocol entity does when it acts as a SNMP party whose authentication protocol is administratively specified as the Digest Authentication Protocol 🎀. The generic behaviour for sending protocol messages is already defined in [2], so this section only covers the parts that are specific to Digest. Mainly, it covers wrapping a SNMP management communication up into a SNMP authenticated management communication.

According to [2], a SnmpAuthMsg value is built during Step 3 of generic processing. Specifically, its authInfo component gets built according to the authentication protocol identified for the SNMP party that's originating the message. When that protocol is the Digest Authentication Protocol, whenever a management communication is about to be sent by a SNMP party, the entity follows these steps 💅:

  1. The local database is checked to find the authentication clock, last-timestamp, nonce, and private authentication key of the SNMP party originating the message. You get these following the conventions defined in Section 2.4.1, for example 🗂️.
  2. The authTimestamp component is set to the authentication clock value that was just retrieved.
  3. If the last-timestamp is equal to the authentication clock, the nonce gets incremented. Otherwise, the nonce is set to zero. The authNonce component is then set to the nonce value. In the local database, the originating SNMP party's nonce gets set to that nonce value, and its last-timestamp gets set to the authentication clock 📝.
  4. The authentication digest is temporarily set to the private authentication key. The SnmpAuthMsg value is serialized according to the conventions of [12] and [1]. A digest is then computed over the octet sequence representing that serialized value, using for example the algorithm specified in Section 2.4.1. The authDigest component is set to that computed digest value 🔑.

As set forth in [2], the SnmpAuthMsg value then gets encapsulated according to the appropriate privacy protocol into a SnmpPrivMsg value. That SnmpPrivMsg value is serialized and sent to the receiving SNMP party 🚀.

4.2 Receiving a Message

this section covers what a SNMP protocol entity does when a protocol message arrives from a SNMP party whose authentication protocol is administratively specified as the Digest Authentication Protocol 👀. Just like with sending, the generic receiving behaviour is defined in [2], so only the Digest-specific parts show up here.

According to [2], a SnmpAuthMsg value gets evaluated during Step 9 of generic processing. More precisely, the SnmpAuthMsg value is evaluated according to the authentication protocol identified for the SNMP party that originated the message. When that protocol is the Digest Authentication Protocol, whenever a management communication gets received by a SNMP party, the entity goes through the following steps 🫧:

  1. If the ASN.1 type of the authInfo component is not AuthInformation, the message is evaluated as unauthentic. Otherwise, the authTimestamp, authNonce, and authDigest components get extracted from the SnmpAuthMsg value.
  2. The local database is checked to find the authentication clock, last-timestamp, nonce, private authentication key, and lifetime of the SNMP party that originated the message. Those private authentication keys follow the conventions defined in Section 2.4.1, for example 🗝️.
  3. If the authTimestamp component plus the lifetime is less than the authentication clock, the message is evaluated as unauthentic ⌛.
  4. If the authTimestamp component is less than the last-timestamp recorded for the originating party in the local database, the message is evaluated as unauthentic.
  5. If the authTimestamp component is equal to the last-timestamp and the authNonce component is less than or equal to the nonce, the message is evaluated as unauthentic.
  6. The authDigest component gets extracted and temporarily recorded.
  7. 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 corresponding components in the received SnmpAuthMsg value. This new SnmpAuthMsg value is serialized according to the conventions of [12] and [1]. A digest is computed over the octet sequence representing that serialized value, using for example the algorithm specified in Section 2.4.1 🧮.
  8. If the computed digest value is not equal to the previously recorded digest value, the message is evaluated as unauthentic 💀.
  9. The message is evaluated as authentic ✅.
  10. The last-timestamp and nonce values recorded locally for the originating SNMP party are set to the authTimestamp value and the authNonce value, respectively.
  11. The authentication clock value recorded locally for the originating SNMP party is advanced to the authTimestamp value, but only if that authTimestamp value is greater than the recorded one ⏩.
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 [2]. Don't skip this part, bestie, a failed check means the message is thrown away 🚨.

5. Symmetric Privacy Protocol ✨

okay so this section is all about the Symmetric Privacy Protocol 🔐 and its whole vibe is protection from disclosure of a received message 💅. basically, an appropriate chunk of the message gets encrypted with a secret key that only the originator and the recipient know. nobody else gets to peek 🙈

this protocol assumes the underlying mechanism is a symmetric encryption algorithm 🦋. also, the message being encrypted must be protected according to the conventions of the Digest Authentication Protocol. so digest first, then encrypt, periodt 💖

recall from [2] that a SNMP 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 SNMP private management communication, the following statements are true 👑

  • its privDst component is called the privacy destination 🌸 and it identifies the SNMP party the communication is directed to
  • its privData component is called the privacy data ✨ and it represents the (possibly encrypted) serialization (according to the conventions of [12] and [1]) of a SNMP authenticated management communication

5.1. Generating a Message

this section is about what a SNMP protocol entity does when it talks to a SNMP party whose privacy protocol is administratively set to the Symmetric Privacy Protocol 🧚. the generic behaviour of a SNMP protocol entity when it transmits a message is already defined in [2], so this part only covers the bits that are specific to the Symmetric Privacy Protocol 💅. in particular, it describes how a SNMP authenticated management communication gets wrapped up into a SNMP private management communication 🎁

according to [2], a SnmpPrivMsg value gets constructed during Step 5 of generic processing 🔥. specifically, its privData component is constructed according to the privacy protocol identified for the SNMP party receiving the message. when the relevant privacy protocol is the Symmetric Privacy Protocol, here's what a SNMP protocol entity does every time a management communication is going out from a SNMP 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 further processing 🙅‍♀️
  2. the local database is consulted to determine the private privacy key of the SNMP party receiving the message (represented, for example, according to the conventions defined in Section 2.4.2) 🗝️
  3. the SnmpAuthMsg value is serialized according to the conventions of [12] and [1] 📦
  4. the octet sequence representing the serialized SnmpAuthMsg value is encrypted using, for example, the algorithm specified in Section 2.4.2 and the extracted private privacy key 🔐
  5. the privData component is set to the encrypted value 🌈

as set forth in [2], the SnmpPrivMsg value is then serialized and transmitted to the receiving SNMP party 🦋

5.2. Receiving a Message

this section covers the other side of the coin 🪞. it describes what a SNMP protocol entity does when it acts as a SNMP party whose privacy protocol is administratively set to the Symmetric Privacy Protocol. again, the generic receiving behaviour is defined in [2], so only the Symmetric Privacy Protocol specifics get spelled out here 🫶

according to [2], the privData component of a received SnmpPrivMsg value gets evaluated during Step 4 of generic processing ⭐. more specifically, it's evaluated according to the privacy protocol identified for the SNMP party receiving the message. when the relevant privacy protocol is the Symmetric Privacy Protocol, the receiving steps look like this 🍓

  1. the local database is consulted to determine the private privacy key of the SNMP party receiving the message (represented, for example, according to the conventions defined in Section 2.4.2) 🗝️
  2. the contents octets of the privData component are decrypted using, for example, the algorithm specified in Section 2.4.2 and the extracted private privacy key 🔓

processing of the received message continues as specified in [2] 💖

6. Clock and Secret Distribution ✨

okay this part is the big one for keeping everything in sync 🕰️🤫. the protocols in Sections 4 and 5 assume that clocks are loosely synchronized and that there are shared secret values floating around. three requirements constrain the strategy you use to distribute clock values and secrets, and they're honestly so important 😭

  • if the value of an authentication clock is decreased, the last-timestamp and private authentication key must be changed concurrently 🚨

so here's the tea. when the value of an authentication clock goes down, messages that were sent with a timestamp between the clock's value and its new value may be replayed 🙈. changing the private authentication key shuts that threat down. BUT changing the authentication clock and the private authentication key isn't enough by itself 💀. if the last-timestamp doesn't get reduced to match the authentication clock, no message will be considered authentic until the clock value goes past the last-timestamp. so yeah, it's a whole package 💅

  • the private authentication key and private privacy key must be known only to the parties requiring knowledge of them 🔑

protecting these secrets from disclosure is critical to the security of the protocols 😤. if the secrets get distributed over a network, they must be protected with a protocol that supports confidentiality, e.g., the Symmetric Privacy Protocol 🔐. knowledge of the secrets also needs to be as restricted as possible within an implementation. although the secrets may be known to one or more persons during the initial configuration of a device, the secrets should be changed immediately after configuration so that their actual value is known only to the software 🤖. a management station has the extra job of recovering the state of all parties whenever it boots, and it may handle that by recording the secrets on a long-term storage device 💾. access to information on that device must be as restricted as is practically possible 🔒

  • there must exist at least one SNMP protocol entity that assumes 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 may share this responsibility, but their coordination is essential to the secure management of the network 🤝. the mechanism by which multiple management stations make sure 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 SNMP protocol entity 🛠️. the next two sections describe one strategy for distributing clock values and one for working out a synchronized clock value among SNMP parties that support the Digest Authentication Protocol 🕰️. for SNMP parties that support the Symmetric Privacy Protocol, the next section describes a strategy for distributing secret values 🗝️. the last section lays out the procedures a SNMP protocol entity follows to recover from a "crash" 💥

6.1. Initial Configuration

this section is about the initial configuration of a SNMP protocol 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 has to be done manually 🧑‍🔧. that means a person must physically visit the device and enter the initial secret values for at least its first secure SNMP party 📍. this requirement suggests that the person will know the initial secret values 👀

in general, a system is more secure when fewer entities know a secret 🔐. making a person physically visit a device every time a SNMP party is configured not only exposes the secrets unnecessarily, it's also administratively prohibitive 🙃. for example, 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 initialization vector 🔢. clearly, these values need to be recorded on some 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 SNMP parties for each SNMP protocol entity, one pair of which may be used initially to configure all other SNMP parties 🎀

there's actually a minimal, useful set of SNMP 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 SNMP party for which the authentication protocol and privacy protocol are the values noAuth and noPriv, respectively
  • a SNMP party for which the authentication protocol identifies the mechanism defined in Section 2.4.1 and its privacy protocol is the value noPriv
  • a SNMP party for which the authentication protocol and privacy protocol identify the mechanisms defined in Section 2.4.1 and Section 2.4.2, respectively

the last of these SNMP parties, in both the responsible management station and the managed agent, could be used to configure all other SNMP parties 💖. it's the only suitable party for this job because it's the only one that supports data confidentiality, which is necessary to protect the distributed secrets from disclosure to unauthorized entities 🔐

configuring one pair of SNMP parties to be used for configuring all the other parties has the perk of exposing only one pair of secrets, namely 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, secrets are only known to the peers that need them in order to communicate 🫶

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

Okay bestie, so all 6 parties should be set up in each new managed agent AND its responsible management station 💖 The management station should go first 🎀 because it's the one that can generate the starting secrets and hand them to a person on a suitable medium, so they can be delivered to the managed agent 🫶 Here's the step-by-step glow-up for setting up an agent and its management station ✨

  1. Figure out the starting values for every attribute of the SNMP party you're setting up 🧚 Some of these values may be computed by the responsible management station, some may be specified in the MIB document, and some may be decided administratively 💅
  2. Set up the parties in the responsible management station using that set of starting values 🌸 If the management station is computing some starting values to put into the agent, an appropriate medium must be present to record the values 📝
  3. Set up the parties in the managed agent using that same set of starting values 🦋
  4. The responsible management station must synchronize the authentication clock values for each party it shares with each managed agent ⏰ Section 6.3 specifies one strategy by which this could be accomplished 💜
  5. The responsible management station should change the secret values that were manually configured, so the actual values are known only to the peers that need them to talk to each other 🔐 To do this, the management station generates new secrets for each party being reconfigured and distributes them with a strategy that uses a protocol protecting them from disclosure, e.g., Symmetric Privacy Protocol (see Section 6.4) 🧁 Once it gets positive acknowledgement that the new values were distributed, the management station should update its local database with the new values 👑

If the managed agent does not support a protocol that protects messages from disclosure, then automatic maintenance and configuration of parties is not possible. Aka the last step above is not possible 🙈 The secrets can only be changed by a physical visit to the device 🚗

If there are other SNMP protocol entities that need to know the secrets, the responsible management station must distribute the info once the initial configuration is done 📦 The mechanism used must protect the secrets from disclosure to unauthorized entities 🚫 The Symmetric Privacy Protocol, for example, is an acceptable mechanism 💖

6.2. Clock Distribution 🕰️✨

A responsible management station must ensure that the authentication clock value for each SNMP party it's responsible for:

  • is loosely synchronized among all the local databases where it shows up,
  • 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 bunch of ways, including knowing how accurate the system clock is, unauthenticated queries of the party database, and noticing authentication failures that came from the party 👀

Whenever clock skew is detected, and whenever the SNMP entities at both the responsible management station and the relevant managed agent support an appropriate privacy protocol (e.g., the Symmetric Privacy Protocol), the easy-peasy fix is changing the authentication clock and the private key at the same time for the relevant SNMP party 💅 If the request to change the key and clock for a particular party comes from that same party, then, before sending it, the local notion of the authentication clock gets artificially advanced so the request is accepted as authentic 🔑

Generally though, an authentication clock value doesn't need to be kept secret. So it's not necessary that a managed agent support a privacy protocol for the responsible management station to fix skewed clock values 🌈 The general-case procedure is in Section 6.3 💕

In addition to correcting skewed notions of authentication clocks, every SNMP entity must react correctly as an authentication clock approaches its maximal value 🚨 If the authentication clock for a particular SNMP party ever reaches the maximal time value, the clock must halt at that value. (The value of interest may be the maximum less lifetime. When authenticating a message, its authentication timestamp is added to lifetime and compared to the authentication clock. A SNMP protocol entity must guarantee that the sum is never greater than the maximal time value.) In this state, the only authenticated request a management station should generate for this party is one that alters the value of at least its authentication clock and private authentication key 🥺 To reset these values, the responsible management station may set the authentication timestamp in the message to the maximal time value. In this case, the nonce value may be used to distinguish multiple messages 🧩

The value of the authentication clock for a particular SNMP party must never be altered such that its new value is less than its old value, unless its last-timestamp and private authentication key are also altered at the same time 🙅‍♀️

6.3. Clock Synchronization ⏰

Unless the secrets are changed at the same time, the correct way to sync clocks is to advance the slower clock to be equal to the faster clock 🐢➡️🐇 Suppose party agentParty is realized by the SNMP entity in a managed agent. Suppose party mgrParty is realized by the SNMP entity in the matching responsible management station. For any pair of parties, there are four possible conditions of the authentication clocks that could need correcting 👯

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

The selective clock acceleration mechanism built into the protocol fixes conditions 2 and 3 as part of the normal processing of an authentic message 🔧 So the clock adjustment procedure below doesn't do anything for those cases. Instead, the steps below show how the clocks may be synchronized when condition 1, condition 4, or both of those conditions are showing up 👀

  1. The responsible management station saves its existing notions of the authentication clocks for the two parties agentParty and mgrParty 💾
  2. The responsible management station retrieves the authentication clock values for both agentParty and mgrParty from the agent. This retrieval must be an unauthenticated request, since the management station doesn't know if the clocks are synchronized. If the request fails, the clocks cannot be synchronized, and the clock adjustment procedure is aborted without any further processing 🛑
  3. If the management station's notion of the authentication clock for agentParty is ahead of the notion just retrieved from the agent by more than the amount of the communications delay between the two protocol entities, then condition 1 is showing up. The recommended estimate of communication delay in this context is one half of the lifetime value recorded for agentParty 📏
  4. If the notion of the authentication clock for mgrParty just retrieved from the agent is ahead of the management station's notion, then condition 4 is showing up, and the responsible management station advances its notion of the authentication clock for mgrParty to match the agent's notion 🏃‍♀️
  5. If condition 1 is showing up, then the responsible management station sends an authenticated management operation to the agent that advances the agent's notion of the authentication clock for agentParty to be equal to the management station's notion. If this management operation fails, then the management station restores its previously saved notions of the clock values, and the clock adjustment procedure is aborted without any further processing 🔙
  6. The responsible management station retrieves the authentication clock values for both agentParty and mgrParty from the agent. This retrieval must be an authenticated request, so the management station can verify that the clock values are properly synchronized. If this authenticated query fails, then the management station restores its previously saved notions of the clock values, and the clock adjustment procedure is aborted without any further processing. Otherwise, clock synchronization has been successfully realized 🎉
It is important to note that step 4 above must be completed before attempting step 5. Otherwise, the agent may evaluate the request in step 5 as unauthentic. Similarly, step 5 above must be completed before attempting step 6. Otherwise, the management station may evaluate the query response in step 6 as unauthentic 🚩

Administrative advancement of a clock as described above does not introduce any new vulnerabilities, since the value of the clock is meant to increase with the passage of time 🕰️ A potential operational problem is the rejection of management operations that are authenticated using a previous value of the relevant party clock. This possibility may be avoided if a management station suppresses generation of management traffic between relevant parties while this clock adjustment procedure is in progress 🤫

6.4. Secret Distribution 🔐

This section describes one strategy by which a SNMP protocol entity that supports both the Digest Authentication Protocol and the Symmetric Privacy Protocol can change the secrets for a particular SNMP party 🧑‍💻

How often the secrets of a SNMP party should be changed is a local administrative issue. However, the more often a secret is 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 7). Note that, thanks to both administrative and automatic advances of the authentication clock described in this memo, the authentication clock for a SNMP party may well approach its maximal value sooner than might otherwise be expected ⚠️

The following sequence of steps specifies how a responsible management station alters a secret value (i.e., the private authentication key or the private privacy key) for a particular SNMP party 🍓

  1. The responsible management station generates a new secret value 🎲
  2. The responsible management station encapsulates a SNMP Set request in a SNMP 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. 🫶
  1. Next, the SNMP private management communication gets transmitted to its destination. 🚀
  2. Once the request lands, the recipient processes the message according to [1] and [2]. Main character energy 👑
  3. The recipient then wraps a SNMP Set response inside a SNMP private management communication with at least these 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.
  4. The SNMP private management communication gets transmitted to its destination. 🦋
  5. When the response arrives, the responsible management station updates its local database with the new value. Slay 💅

Okay, so if the responsible management station never gets a response to its request, there are two possible reasons. 😭

  • 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 those two apart, a responsible management station could check the destination to see if the change has happened. Unfortunately, the secret values are unreadable, so that's not directly possible. 🙈

The recommended strategy for verifying key changes is to set the public value that goes with the secret being changed to a recognizable, novel value. Basically, change the public authentication key value for the relevant party when you change its private authentication key, or change its public privacy key value when you change its private privacy key. That way the responsible management station can grab the public value when no response comes back and check whether the change actually happened. 🌸 (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 matter in this context. Of course, protocols that use the public values may use this strategy directly.) 🧚

One more scenario is worth mentioning, and it's when a SNMP party changes its own secrets. In this case, the destination updates its local database before it generates a response, so the response gets built with the new value. Meanwhile, the responsible management station won't update its local database until after the response arrives. This means the responsible management station may receive a response that gets evaluated as unauthentic, unless it uses the correct secret. ngl that's a plot twist 💀 The responsible management station may either handle this as a special case, or use an alteration of the relevant public values (as described above) to verify the key change. 🎀

Also, between sending the request and getting the response, the management station must keep track of both the old and new secret values. The delay might be caused by a network failure, so the management station must be ready to hold on to both values for an extended period of time, including across reboots. 🔒

6.5. Crash Recovery 🧊

This section lays out what SNMP protocol entities have to do to recover from system crashes or other service interruptions. 🛠️

For each SNMP party in the local database of a particular SNMP protocol entity, its identity, authentication clock, private authentication key, and private privacy key must have non-volatile, incorruptible representations. If possible, the lifetime should also have a non-volatile, incorruptible representation. If said protocol entity supports other security protocols or algorithms in addition to 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 SNMP party is a critical piece of the overall security of the protocols. Including a reliable representation of a clock in a SNMP protocol entity boosts overall security. A reliable clock representation keeps increasing as time passes, even when the local SNMP protocol entity may not be operating because of power loss or some other system failure. An example is the battery-powered clock-calendar devices built into some modern systems. It is assumed that management stations always support reliable clock representations, and clock adjustment by a human operator during crash recovery may add to 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, then upon reboot the clock must be halted at its maximal value. The procedures specified in Section 6.3 would then apply. 🚨

If a managed network element supports a reliable clock representation, recovering from a crash takes few special actions. Upon recovery, the attributes of each SNMP party that don't have a non-volatile or reliable representation get initialized as follows: 🌈

  • 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 2.4.1.
  • The last-timestamp is initialized to the value of the authentication clock.
  • The nonce is initialized to zero.
  • 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 2.4.2.

Upon detecting that a managed agent has rebooted, a responsible management station must reset all of the 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 that the message will be authentic when the recipient receives it. ⏩

If, on the other hand, a managed network element does not support a reliable clock representation, then the attributes of each SNMP party that don't have a non-volatile representation get initialized as follows: 🥺

  • 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 2.4.1.
  • The authentication clock is initialized to the maximal time value.
  • The last-timestamp is initialized to the maximal time value.
  • The nonce is initialized to zero.
  • 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 2.4.2.

The only authenticated request a management station should generate for a party in this initial state is one that changes the value of at least its authentication clock, private authentication key, and lifetime (if that wasn't retained). To reset these values, the responsible management station must set the authentication timestamp in the message to the maximal time value. The nonce value may be used to tell multiple messages apart. 🦋

7. Security Considerations 🔐

This section spotlights security considerations for the protocols and procedures in this memo. Practices that help the mechanisms defined here operate securely and effectively come first. Next up are the constraints on implementation behavior that are necessary for the security of the system. Last, there's an informal look at how each mechanism of the protocols contributes to the required goals. Bestie, read this one closely 🫶

This section describes practices that contribute to the secure, effective operation of the mechanisms defined in this memo. ✨

  • A management station should discard SNMP responses for which neither the request-id component nor the represented management information corresponds to any currently outstanding request.

Sure, a management station would usually do this as a matter of course, but in the context of these security protocols it matters a lot because messages might get duplicated, maliciously or otherwise. 👀

  • A management station should not interpret an agent's lack of response to an authenticated SNMP management communication as a conclusive indication of agent or network failure.

Authentication failure traps can be lost or suppressed because of authentication clock skew or inconsistent notions of shared secrets. To make it easier to administer such SNMP 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 SNMP 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 will be able to verify all clock values. 🕰️

A large lifetime makes it easier for malicious actors to delay SNMP messages. When explicitly authorized, the implementation of a management station may provide for dynamic adjustment of the lifetime to accommodate changing network conditions. 🚦

  • When sending state altering messages to a managed agent, a management station should delay sending successive messages to that agent until a positive acknowledgement is received for the previous message or until the previous message expires. 🛑

When using the noAuth protocol, SNMP doesn't impose any message ordering. Messages may be received in any order relative to when they were generated, and each one gets processed in the order it was received. The security protocols, on the other hand, guarantee that received messages are ordered, insofar as each received message must have been sent after a previously received message was sent. 📬

When an authenticated message gets sent to a managed agent, it's only valid for a window of time that doesn't go past lifetime under normal circumstances ⏳. So if the management station sends another authenticated message and the agent receives and processes that one before the first, the first one is going to be considered unauthentic when it finally shows up 💀. Harsh, but that's the vibe.

Also, a management station MUST cope with messages getting lost or reordered because of network weirdness as a matter of course 🌀. That's just part of the job, bestie. A management station implementation MAY choose to prevent losses caused by reordering when it uses the security protocols from this memo, by delaying when it sends successive messages 🐢.

  • 🔑 The frequency with which the secrets of a SNMP party SHOULD be changed is indirectly related to how often they get used.

Protecting the secrets from disclosure is literally critical to the whole security situation 🚨. Using a secret a lot gives a cryptanalyst a steady stream of data to dig through, looking for known or perceived weaknesses in an algorithm. Changing the secret often shuts that down 🔒.

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

Also, in a local environment the threat of disclosure MAY be insignificant, so the changing of secrets MAY be less frequent. But when public data networks are the communication paths, more caution is prudent 👀.

  • 🫶 In order to get the greatest degree of security, a management station implementation MUST support constrained, pairwise sharing of secrets among SNMP entities as its default mode of operation.

Because these protocols use symmetric cryptography, the secrets for a particular SNMP party MUST be known to all other SNMP parties that party MAY wish to communicate with. The more places a secret lives, the more likely it is to leak, and the bigger the damage 😱. Plus, if more than two protocol entities know a particular secret, data origin can't be reliably authenticated, because it's impossible to tell with any certainty which of them actually sent a given SNMP message. So the greatest security comes from setups where each SNMP party's secrets are known to at most two protocol entities 💜.

7.2. Conformance 📋

A SNMP protocol entity implementation that claims conformance to this memo MUST satisfy the following requirements:

  1. It MUST implement the noAuth and noPriv protocols, whose object identifiers are defined in [4].
    • noAuth means messages a party generates with it are not protected as to origin or integrity. It's REQUIRED to make sure a party's authentication clock is always accessible 🕰️.
    • noPriv means messages a party receives with it are not protected from disclosure. It's REQUIRED to make sure a party's authentication clock is always accessible 🕰️.
  2. It MUST implement the Digest Authentication Protocol in conjunction with the algorithm defined in Section 2.4.1.
  3. It MUST include in its local database at least one SNMP party with the following parameters set as follows:
    • partyAuthProtocol is set to noAuth, and
    • partyPrivProtocol is set to noPriv.

This party MUST have a MIB view [2] 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 SNMP party about which it keeps information 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 2.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 SNMP messages with respect to that party. This prohibition includes preventing read-access by the entity's human operators 🙅‍♀️.
    • (c) It MUST allow the party's authentication clock to be publicly accessible. The Digest Authentication Protocol only works right if this value can be determined at all times, which is what guarantees 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) In the event that 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 🔄.
  2. If it selects new value(s) for a party's secret(s), it MUST avoid bad or obvious choices for said secret(s). The choices to avoid are boundary values (such as all-zeros) and predictable values (such as the same value as previously or selecting from a predetermined set) 🚫.

7.3. Protocol Correctness 🧠

The correctness of these SNMP 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 SNMP party are known only to authorized SNMP protocol entities.
  6. Local notions of the authentication clock for a particular SNMP 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; they are intended to be self-explanatory 🧚.

7.3.1. Clock Monotonicity Mechanism ⏩

By pairing each sequence of a clock's values with a unique key, the protocols partially realize goals 3 and 4. 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 📈.

7.3.2. Data Integrity Mechanism 🛡️

The protocols require computation of a message digest over the SNMP 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 enough to guarantee data integrity, since the digest value can be modified along with the message while it's enroute. However, since not all of the digested message is included in the transmission to the destination, it's 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 SNMP message modification that appends extraneous material to the end of such messages. However, because SNMP messages are represented 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 SNMP messages. A more general data integrity service that protects 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 still provided by other mechanisms of the protocol 🔁.

7.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 💜.

7.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 a pseudocode fragment below. This pseudocode fragment meets the requirements of assumption 6 🌸.

Pseudocode Fragment. 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 SNMP 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;
    }
}

okay bestie, these two functions are giving key-and-clock tag-team energy 👯‍♀️ each one checks a flag, then either swaps the live values in or parks the new one in a cache 🎀

7.3.5. Ordered Delivery Mechanism

okay so the Digest Authentication Protocol says a message whose timestamp is not greater than the timestamp of the most recent validated message already delivered from that same originating party does not get delivered 🙅‍♀️ otherwise, we update our record of the last delivered timestamp 📝

if (msgIsValidated) {
    if (timestampOfReceivedMsg >
       party->timestampOfLastDeliveredMsg) {
       party->timestampOfLastDeliveredMsg =
          timestampOfReceivedMsg;
    }
    else {
       msgIsValidated = FALSE;
    }
}

not explicitly in the pseudocode above, but ngl this part is so important 🥺 in the Digest Authentication Protocol, the ordered delivery mechanism has to make sure that when a received message's authentication timestamp equals the last-timestamp, messages keep getting delivered as long as their nonce values keep going up 📈 that's how the protocols hit goal 4 🏆

7.3.6. Message Timeliness Mechanism

the SNMP security protocols say that if a received message's authentication timestamp, plus an administratively chosen lifetime value, is still less than the local notion of the clock for the originating SNMP party, then the message does not get delivered ⏰

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

this is how the protocols realize goal 3 🎯 when the local notions of a particular SNMP party clock are pretty well synchronized, the timeliness mechanism actually limits how old a validly delivered message can be 🕰️✨ so if some attacker scoops up all the validated messages and tries to replay them much later 😱, the delay that attack can cause is limited to a period proportional to the skew among the local notions of the party clock. not a free pass for the attacker, periodt 💅

7.3.7. Selective Clock Acceleration Mechanism

the SNMP security protocols say that if a received, validated message has a timestamp that's ahead of the local notion of the clock for the originating party, then that local notion gets moved forward to match the timestamp 🚀 this mechanism is neither strictly necessary nor sufficient for the security of the protocol 🙈 instead it helps the clock synchronization that valid message delivery depends on, which makes the protocol work better in a management context 💜

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

the effect here is to bring the local notions of the party clock closer together when the sender's notion is further ahead than the receiver's 👀 in the opposite case, this mechanism does nothing to the local notions of the party clock, and the received message is either validly delivered or not, depending on the other mechanisms in the protocol 🤷‍♀️

running this mechanism doesn't, in general, boost the odds of validated delivery for messages from party participants whose local notion of the party clock is behind 😬 so queries from a management station might not get validly delivered, and the management station needs to react appropriately (for example, by administratively resynchronizing the local notions of the clock together with a key change) 🔑 trap messages from an agent with a lagging party clock are a bigger problem 💀 the agent might not even have the capacity to notice and react to the security failures that stop its messages from being delivered. so the already unreliable nature of trap messages is likely to get worse if people try to add validated delivery on top 😭

7.3.8. Confidentiality Mechanism

the protocols require a symmetric encryption algorithm whenever the data confidentiality service is required 🔐 with this mechanism plus assumption 3, the protocols realize goal 5 🫶

8. Acknowledgements 🌸

the authors want to thank the members of the SNMP Security Working Group of the IETF for their patience and comments 🥰 huge special thanks to Jeff Case, who provided the first implementation of the protocols 👑 Dave Balenson, John Linn, Dan Nessett, and everyone in the Privacy and Security Research Group gave tons of valuable and detailed comments 💖

9. References 📚

[1] Case, J., M. Fedor, M. Schoffstall, and J. Davin, The Simple Network Management Protocol", RFC 1157, University of Tennessee at Knoxville, Performance Systems International, Performance Systems International, and the MIT Laboratory for Computer Science, May 1990. (Obsoletes RFC 1098.)

[2] Davin, J., Galvin, J., and K. McCloghrie, "SNMP Administrative Model", RFC 1351, MIT Laboratory for Computer Science, Trusted Information Systems, Inc., Hughes LAN Systems, Inc., July 1992.

[3] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, MIT Laboratory for Computer Science, April 1992.

[4] McCloghrie, K., Davin, J., and J. Galvin, "Definitions of Managed Objects for Administration of SNMP Parties", RFC 1353, Hughes LAN Systems, Inc., MIT Laboratory for Computer Science, Trusted Information Systems, Inc., July 1992.

[5] FIPS Publication 46-1, "Data Encryption Standard", National Institute of Standards and Technology, Federal Information Processing Standard (FIPS); Supersedes FIPS Publication 46, January 15, 1977; Reaffirmed January 22, 1988.

[6] ANSI X3.92-1981, "Data Encryption Algorithm", American National Standards Institute, December 30, 1980.

[7] FIPS Publication 81, "DES Modes of Operation", National Institute of Standards and Technology, December 2, 1980, Federal Information Processing Standard (FIPS).

[8] ANSI X3.106-1983, "Data Encryption Algorithm - Modes of Operation", American National Standards Institute, May 16, 1983.

[9] FIPS Publication 74, "Guidelines for Implementing and Using the NBS Data Encryption Standard", National Institute of Standards and Technology, April 1, 1981. Federal Information Processing Standard (FIPS).

[10] Special Publication 500-20, "Validating the Correctness of Hardware Implementations of the NBS Data Encryption Standard", National Institute of Standards and Technology.

[11] Special Publication 500-61, "Maintenance Testing for the Data Encryption Standard", National Institute of Standards and Technology, August 1980.

[12] Information Processing -- Open Systems Interconnection -- Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1), International Organization for Standardization/International Electrotechnical Institute, 1987, International Standard 8825.

10. Authors' Addresses 🦋

these are the people who made it all happen, bestie 🧚 reach out if you ever want to chat about it 💌

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

Phone:  (301) 854-6889
EMail:  galvin@tis.com


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

Phone:  (415) 966-7934
EMail:  kzm@hls.com


James R. Davin
MIT Laboratory for Computer Science
545 Technology Square
Cambridge, MA 02139

Phone:  (617) 253-6020
EMail:  jrd@ptt.lcs.mit.edu
📦 where this page comes from