Network Working Group J. Galvin
` Request for Comments: 1446 Trusted Information Systems
` K. McCloghrie
` Hughes LAN Systems
` April 1993
`
`
` Security Protocols
` for version 2 of the
` Simple Network Management Protocol (SNMPv2)
`
`
` Status of this Memo
`
` This RFC specifes an IAB standards track protocol for the
` Internet community, and requests discussion and suggestions
` for improvements. Please refer to the current edition of the
` "IAB Official Protocol Standards" for the standardization
` state and status of this protocol. 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
`
`
`
`
`Hewlett Packard Exhibit 1037, Page 1 of 53
`Hewlett Packard Enterprise Company v. Intellectual Ventures II LLC
`IPR2021-01377
`
`

`

`
` Galvin & McCloghrie [Page i]
`
`Hewlett Packard Exhibit 1037, Page 2 of 53
`Hewlett Packard Enterprise Company v. Intellectual Ventures II LLC
`IPR2021-01377
`
`

`

` RFC 1446 Security Protocols for SNMPv2 April 1993
`
`
` 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
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
` Galvin & McCloghrie [Page 1]
`
`Hewlett Packard Exhibit 1037, Page 3 of 53
`Hewlett Packard Enterprise Company v. Intellectual Ventures II LLC
`IPR2021-01377
`
`

`

` RFC 1446 Security Protocols for SNMPv2 April 1993
`
`
` 1. Introduction
`
` A network management system contains: several (potentially
` many) nodes, each with a processing entity, termed an agent,
` which has access to management instrumentation; at least one
` management station; and, a management protocol, used to convey
` management information between the agents and management
` stations. Operations of the protocol are carried out under an
` administrative framework which defines both authentication and
` authorization policies.
`
` Network management stations execute management applications
` which monitor and control network elements. Network elements
` are devices such as hosts, routers, terminal servers, etc.,
` which are monitored and controlled through access to their
` management information.
`
` In the Administrative Model for SNMPv2 document [1], each
` SNMPv2 party is, by definition, associated with a single
` authentication protocol and a single privacy protocol. It is
` the purpose of this document, Security Protocols for SNMPv2,
` to define one such authentication and one such privacy
` protocol.
`
` The authentication protocol provides a mechanism by which
` SNMPv2 management communications transmitted by the party may
` be reliably identified as having originated from that party.
` The authentication protocol defined in this memo also reliably
` determines that the message received is the message that was
` sent.
`
` The privacy protocol provides a mechanism by which SNMPv2
` management communications transmitted to said party are
` protected from disclosure. The privacy protocol in this memo
` specifies that only authenticated messages may be protected
` from disclosure.
`
` These protocols are secure alternatives to the so-called
` "trivial" protocol defined in [2].
`
` 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.
`
`
`
`
`
`
` Galvin & McCloghrie [Page 2]
`
`Hewlett Packard Exhibit 1037, Page 4 of 53
`Hewlett Packard Enterprise Company v. Intellectual Ventures II LLC
`IPR2021-01377
`
`

`

` RFC 1446 Security Protocols for SNMPv2 April 1993
`
`
` The Digest Authentication Protocol is described in Section 3.
` It provides a data integrity service by transmitting a message
` digest - computed by the originator and verified by the
` recipient - with each SNMPv2 message. The data origin
` authentication service is provided by prefixing the message
` with a secret value known only to the originator and
` recipient, prior to computing the digest. Thus, data
` integrity is supported explicitly while data origin
` authentication is supported implicitly in the verification of
` the digest.
`
` The Symmetric Privacy Protocol is described in Section 4. It
` protects messages from disclosure by encrypting their contents
` according to a secret cryptographic key known only to the
` originator and recipient. The additional functionality
` afforded by this protocol is assumed to justify its additional
` computational cost.
`
` The Digest Authentication Protocol depends on the existence of
` loosely synchronized clocks between the originator and
` recipient of a message. The protocol specification makes no
` assumptions about the strategy by which such clocks are
` synchronized. Section 5.3 presents one strategy that is
` particularly suited to the demands of SNMP network management.
`
` Both protocols described here require the sharing of secret
` information between the originator of a message and its
` recipient. The protocol specifications assume the existence
` of the necessary secrets. The selection of such secrets and
` their secure distribution to appropriate parties may be
` accomplished by a variety of strategies. Section 5.4 presents
` one such strategy that is particularly suited to the demands
` of SNMP network management.
`
`
` 1.1. A Note on Terminology
`
` For the purpose of exposition, the original Internet-standard
` Network Management Framework, as described in RFCs 1155, 1157,
` and 1212, is termed the SNMP version 1 framework (SNMPv1).
` The current framework is termed the SNMP version 2 framework
` (SNMPv2).
`
`
`
`
`
`
`
`
` Galvin & McCloghrie [Page 3]
`
`Hewlett Packard Exhibit 1037, Page 5 of 53
`Hewlett Packard Enterprise Company v. Intellectual Ventures II LLC
`IPR2021-01377
`
`

`

` RFC 1446 Security Protocols for SNMPv2 April 1993
`
`
` 1.2. Threats
`
` Several of the classical threats to network protocols are
` applicable to the network management problem and therefore
` would be applicable to any SNMPv2 security protocol. Other
` threats are not applicable to the network management problem.
` This section discusses principal threats, secondary threats,
` and threats which are of lesser importance.
`
` The principal threats against which any SNMPv2 security
` protocol should provide protection are:
`
`
` Modification of Information
` The SNMPv2 protocol provides the means for management
` stations to interrogate and to manipulate the value of
` objects in a managed agent. The modification threat is
` the danger that some party may alter in-transit messages
` generated by an authorized party in such a way as to
` effect unauthorized management operations, including
` falsifying the value of an object.
`
` Masquerade
` The SNMPv2 administrative model includes an access
` control model. Access control necessarily depends on
` knowledge of the origin of a message. The masquerade
` threat is the danger that management operations not
` authorized for some party may be attempted by that party
` by assuming the identity of another party that has the
` appropriate authorizations.
`
` Two secondary threats are also identified. The security
` protocols defined in this memo do provide protection against:
`
` Message Stream Modification
` The SNMPv2 protocol is based upon a connectionless
` transport service which may operate over any subnetwork
` service. The re-ordering, delay or replay of messages
` can and does occur through the natural operation of many
` such subnetwork services. The message stream
` modification threat is the danger that messages may be
` maliciously re-ordered, delayed or replayed to an extent
` which is greater than can occur through the natural
` operation of a subnetwork service, in order to effect
` unauthorized management operations.
`
`
`
`
`
` Galvin & McCloghrie [Page 4]
`
`Hewlett Packard Exhibit 1037, Page 6 of 53
`Hewlett Packard Enterprise Company v. Intellectual Ventures II LLC
`IPR2021-01377
`
`

`

` RFC 1446 Security Protocols for SNMPv2 April 1993
`
`
` 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 the SNMPv2 is used to create new SNMPv2 parties [1]
` on which subsequent secure operation might be based.
` Protecting against the disclosure threat may also be
` required as a matter of local policy.
`
` There are at least two threats that a SNMPv2 security protocol
` need not protect against. The security protocols defined in
` this memo do not provide protection against:
`
` Denial of Service
` A SNMPv2 security protocol need not attempt to address
` the broad range of attacks by which service to authorized
` parties is denied. Indeed, such denial-of-service
` attacks are in many cases indistinguishable from the type
` of network failures with which any viable network
` management protocol must cope as a matter of course.
`
` Traffic Analysis
` In addition, a SNMPv2 security protocol need not attempt
` to address traffic analysis attacks. Indeed, many
` traffic patterns are predictable - agents may be managed
` on a regular basis by a relatively small number of
` management stations - and therefore there is no
` significant advantage afforded by protecting against
` traffic analysis.
`
`
` 1.3. Goals and Constraints
`
` Based on the foregoing account of threats in the SNMP network
` management environment, the goals of a SNMPv2 security
` protocol are enumerated below.
`
` (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.
`
`
`
`
`
` Galvin & McCloghrie [Page 5]
`
`Hewlett Packard Exhibit 1037, Page 7 of 53
`Hewlett Packard Enterprise Company v. Intellectual Ventures II LLC
`IPR2021-01377
`
`

`

` RFC 1446 Security Protocols for SNMPv2 April 1993
`
`
` (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.
`
` In addition to the principal goal of supporting secure network
` management, the design of any SNMPv2 security protocol is also
` influenced by the following constraints:
`
` (1) When the requirements of effective management in times of
` network stress are inconsistent with those of security,
` the former are preferred.
`
` (2) Neither the security protocol nor its underlying security
` mechanisms should 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
`
` The security services necessary to support the goals of a
` SNMPv2 security protocol are as follows.
`
` Data Integrity
` is the provision of the property that data has not been
` altered or destroyed in an unauthorized manner, nor have
` data sequences been altered to an extent greater than can
` occur non-maliciously.
`
` Data Origin Authentication
` is the provision of the property that the claimed origin
` of received data is corroborated.
`
` Data Confidentiality
` is the provision of the property that information is not
` made available or disclosed to unauthorized individuals,
` entities, or processes.
`
`
`
`
`
`
`
` Galvin & McCloghrie [Page 6]
`
`Hewlett Packard Exhibit 1037, Page 8 of 53
`Hewlett Packard Enterprise Company v. Intellectual Ventures II LLC
`IPR2021-01377
`
`

`

` RFC 1446 Security Protocols for SNMPv2 April 1993
`
`
` 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.
`
` Further, there is no provision for data confidentiality
` without both data integrity and data origin authentication.
`
`
` 1.5. Mechanisms
`
` The security protocols defined in this memo employ several
` types of mechanisms in order to realize the goals and security
` services described above:
`
` o 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.
`
` o 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.
`
` o 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]).
`
` o In support of data confidentiality, a symmetric
` encryption algorithm is required. An appropriate portion
` of the message is encrypted prior to being transmitted to
`
`
`
`
`
` Galvin & McCloghrie [Page 7]
`
`Hewlett Packard Exhibit 1037, Page 9 of 53
`Hewlett Packard Enterprise Company v. Intellectual Ventures II LLC
`IPR2021-01377
`
`

`

` RFC 1446 Security Protocols for SNMPv2 April 1993
`
`
` 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 1.5.1 and 1.5.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.
`
`
` 1.5.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 SNMPv2 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 3) is identified by the
` ASN.1 object identifier value v2md5AuthProtocol, defined in
` [4]. (Note that this protocol is a modified version of the
` md5AuthProtocol protocol defined in RFC 1352.)
`
` For any SNMPv2 party for which the 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.
`
`
`
`
`
`
`
`
`
` Galvin & McCloghrie [Page 8]
`
`Hewlett Packard Exhibit 1037, Page 10 of 53
`Hewlett Packard Enterprise Company v. Intellectual Ventures II LLC
`IPR2021-01377
`
`

`

` RFC 1446 Security Protocols for SNMPv2 April 1993
`
`
` 1.5.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 SNMPv2
` message is encrypted and included as part of the message sent
` to the recipient.
`
` Two organizations have published specifications defining the
` DES: the National Institute of Standards and Technology (NIST)
` [5] and the American National Standards Institute [6]. There
` 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.
`
` o There is a document with guidelines for implementing and
` using the DES, including functional specifications for
` the DES and its modes of operation [9].
`
` o 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.
`
` o 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 4) is identified by the ASN.1
` object identifier value desPrivProtocol, defined in [4].
`
` For any SNMPv2 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.
`
`
`
`
`
` Galvin & McCloghrie [Page 9]
`
`Hewlett Packard Exhibit 1037, Page 11 of 53
`Hewlett Packard Enterprise Company v. Intellectual Ventures II LLC
`IPR2021-01377
`
`

`

` RFC 1446 Security Protocols for SNMPv2 April 1993
`
`
` 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.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
` Galvin & McCloghrie [Page 10]
`
`Hewlett Packard Exhibit 1037, Page 12 of 53
`Hewlett Packard Enterprise Company v. Intellectual Ventures II LLC
`IPR2021-01377
`
`

`

` RFC 1446 Security Protocols for SNMPv2 April 1993
`
`
` 2. SNMPv2 Party
`
` 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 an actual process which performs network
` management operations by generating and/or responding to
` SNMPv2 protocol messages in the manner specified in [12].
` Architecturally, every SNMPv2 entity maintains a local
` database that represents all SNMPv2 parties known to it.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
` Galvin & McCloghrie [Page 11]
`
`Hewlett Packard Exhibit 1037, Page 13 of 53
`Hewlett Packard Enterprise Company v. Intellectual Ventures II LLC
`IPR2021-01377
`
`

`

` RFC 1446 Security Protocols for SNMPv2 April 1993
`
`
` 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 the generation of
` messages using the Digest Authentication Protocol, additional,
` special significance is attributed to certain components of
` that party's representation:
`
` o 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 1.5.1).
` This combined mechanism is used to authenticate the
` origin and integrity of all messages generated by the
` party.
`
`
`
`
`
`
` Galvin & McCloghrie [Page 12]
`
`Hewlett Packard Exhibit 1037, Page 14 of 53
`Hewlett Packard Enterprise Company v. Intellectual Ventures II LLC
`IPR2021-01377
`
`

`

` RFC 1446 Security Protocols for SNMPv2 April 1993
`
`
` o Its partyAuthClock component is called the authentication
` clock and represents a notion of the current time that is
` specific to the party.
`
` o 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.
`
` o 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.
`
`