Network Working Group J. Galvin Request for Comments: 1352 Trusted Information Systems, Inc. K. McCloghrie Hughes LAN Systems, Inc. J. Davin MIT Laboratory for Computer Science July 1992 SNMP Security Protocols Status of this Memo This document specifies 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. 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 Galvin, McCloghrie, & Davin [Page 1] RFC 1352 SNMP Security Protocols July 1992 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 The Simple Network Management Protocol (SNMP) specification [1] allows for the protection of network management operations by a variety of security protocols. The SNMP administrative model described in [2] provides a framework for securing SNMP network management. In the context of that framework, this memo defines protocols to support the following three security services: o data integrity, o data origin authentication, and o data confidentiality. Please send comments to the SNMP Security Developers mailing list (snmp-sec-dev@tis.com). 2. Introduction In the model described in [2], each SNMP party is, by definition, associated with a single authentication protocol. The authentication protocol provides a mechanism by which SNMP 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. Similarly, each SNMP party is, by definition, associated with a single privacy protocol. The privacy protocol provides a mechanism by which SNMP 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 [1]. Galvin, McCloghrie, & Davin [Page 2] RFC 1352 SNMP Security Protocols July 1992 USE OF THE TRIVIAL PROTOCOL ALONE DOES NOT CONSTITUTE SECURE NETWORK MANAGEMENT. THEREFORE, A NETWORK MANAGEMENT SYSTEM THAT IMPLEMENTS ONLY THE TRIVIAL PROTOCOL IS NOT CONFORMANT TO THIS SPECIFICATION. The Digest Authentication Protocol is described in Section 4. It provides a data integrity service by transmitting a message digest -- computed by the originator and verified by the recipient -- with each SNMP 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 5. 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 6.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 6.4 presents one such strategy that is particularly suited to the demands of SNMP network management. 2.1 Threats Several of the classical threats to network protocols are applicable to the network management problem and therefore would be applicable to any SNMP 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 SNMP security protocol should provide protection are: Galvin, McCloghrie, & Davin [Page 3] RFC 1352 SNMP Security Protocols July 1992 Modification of Information. The SNMP 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 SNMP 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 SNMP protocol is based upon connectionless transport services. The message stream modification threat is the danger that messages may be arbitrarily re-ordered, delayed or replayed to effect unauthorized management operations. This threat may arise either by the work of a malicious attacker or by the natural operation of a subnetwork service. 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 SNMP is used to administer private parameters on which its security is based. Protecting against the disclosure threat may also be required as a matter of local policy. There are at least two threats that a SNMP security protocol need not protect against. The security protocols defined in this memo do not provide protection against: Denial of Service. A SNMP 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. Galvin, McCloghrie, & Davin [Page 4] RFC 1352 SNMP Security Protocols July 1992 Traffic Analysis. In addition, a SNMP 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. 2.2 Goals and Constraints Based on the foregoing account of threats in the SNMP network management environment, the goals of a SNMP security protocol are enumerated below. 1. The protocol should provide for verification that each received SNMP 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 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 for 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. In addition to the principal goal of supporting secure network management, the design of any SNMP 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). Galvin, McCloghrie, & Davin [Page 5] RFC 1352 SNMP Security Protocols July 1992 3. A security mechanism should entail no changes to the basic SNMP network management philosophy. 2.3 Security Services The security services necessary to support the goals of a SNMP security protocol are as follows. Data Integrity is the provision of the property that data and data sequences have not been altered or destroyed in an unauthorized manner. 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. 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. 2.4 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 SNMP 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 SNMP 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 reordering, a timestamp value is included in each message generated. A recipient evaluates the timestamp to determine if the Galvin, McCloghrie, & Davin [Page 6] RFC 1352 SNMP Security Protocols July 1992 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. This protection against the threat of message reordering implies no protection against unauthorized deletion or suppression of messages. 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 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. 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