diff options
| author | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
|---|---|---|
| committer | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
| commit | 4bfd864f10b68b71482b35c818559068ef8d5797 (patch) | |
| tree | e3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc1446.txt | |
| parent | ea76e11061bda059ae9f9ad130a9895cc85607db (diff) | |
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc1446.txt')
| -rw-r--r-- | doc/rfc/rfc1446.txt | 3068 |
1 files changed, 3068 insertions, 0 deletions
diff --git a/doc/rfc/rfc1446.txt b/doc/rfc/rfc1446.txt new file mode 100644 index 0000000..885c8ab --- /dev/null +++ b/doc/rfc/rfc1446.txt @@ -0,0 +1,3068 @@ + + + + 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 + + + + + Galvin & McCloghrie [Page i] + + + + + + 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] + + + + + + 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] + + + + + + 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] + + + + + + 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] + + + + + + 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] + + + + + + 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] + + + + + + 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] + + + + + + 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] + + + + + + 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] + + + + + + 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] + + + + + + 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] + + + + + + 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] + + + + + + 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. + + o Its partyAuthLifetime component is called the lifetime + and represents an administrative upper bound on + acceptable delivery delay for protocol messages generated + by the party. + + For each SNMPv2 party that supports the receipt of messages + via the Symmetric Privacy Protocol, additional, special + significance is attributed to certain components of that + party's representation: + + o 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 1.5.2). This combined + mechanism is used to protect from disclosure all protocol + messages received by the party. + + o 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. + + o Its partyPrivPublic component is called the public + privacy key and represents any public value that may be + needed to support the privacy protocol. This component + is not significant except as suggested in Section 5.4. + + + + + + + + + + Galvin & McCloghrie [Page 13] + + + + + + RFC 1446 Security Protocols for SNMPv2 April 1993 + + + 3. Digest Authentication Protocol + + This section describes the Digest Authentication Protocol. It + provides both for verifying the integrity of a received + message (i.e., the message received is the message sent) and + for verifying the origin of a message (i.e., the reliable + identification of the originator). The integrity of the + message is protected by computing a digest over an appropriate + portion of a message. The digest is computed by the + originator of the message, transmitted with the message, and + verified by the recipient of the message. + + A secret value known only to the originator and recipient of + the message is prefixed to the message prior to the digest + computation. Thus, the origin of the message is known + implicitly with the verification of the digest. + + A requirement on parties using this Digest Authentication + Protocol is that they shall not originate messages for + transmission to any destination party which does not also use + this Digest Authentication Protocol. This restriction + excludes undesirable side effects of communication between a + party which uses these security protocols and a party which + does not. + + Recall from [1] that a SNMPv2 management communication is + represented by an ASN.1 value with the following syntax: + + SnmpMgmtCom ::= [2] IMPLICIT SEQUENCE { + dstParty + OBJECT IDENTIFIER, + srcParty + OBJECT IDENTIFIER, + context + OBJECT IDENTIFIER, + pdu + PDUs + } + + For each SnmpMgmtCom value that represents a SNMPv2 management + communication, the following statements are true: + + o Its dstParty component is called the destination and + identifies the SNMPv2 party to which the communication is + directed. + + + + + + Galvin & McCloghrie [Page 14] + + + + + + RFC 1446 Security Protocols for SNMPv2 April 1993 + + + o Its srcParty component is called the source and + identifies the SNMPv2 party from which the communication + is originated. + + o Its context component identifies the SNMPv2 context + containing the management information referenced by the + communication. + + o Its pdu component has the form and significance + attributed to it in [12]. + + Recall from [1] that a SNMPv2 authenticated management + communication is represented by an ASN.1 value with the + following syntax: + + SnmpAuthMsg ::= [1] IMPLICIT SEQUENCE { + authInfo + ANY, - defined by authentication protocol + authData + SnmpMgmtCom + } + + For each SnmpAuthMsg value that represents a SNMPv2 + authenticated management communication, the following + statements are true: + + o Its authInfo component is called the authentication + information and represents information required in + support of the authentication protocol used by both the + SNMPv2 party originating the message, and the SNMPv2 + party receiving the message. The detailed significance + of the authentication information is specific to the + authentication protocol in use; it has no effect on the + application semantics of the communication other than its + use by the authentication protocol in determining whether + the communication is authentic or not. + + o Its authData component is called the authentication data + + + + + + + + + + + + + Galvin & McCloghrie [Page 15] + + + + + + RFC 1446 Security Protocols for SNMPv2 April 1993 + + + and represents a SNMPv2 management communication. + + In support of the Digest Authentication Protocol, an authInfo + component is of type AuthInformation: + + AuthInformation ::= [2] IMPLICIT SEQUENCE { + authDigest + OCTET STRING, + authDstTimestamp + UInteger32, + authSrcTimestamp + UInteger32 + } + + For each AuthInformation value that represents authentication + information, the following statements are true: + + o Its authDigest component is called the authentication + digest and represents the digest computed over an + appropriate portion of the message, where the message is + temporarily prefixed with a secret value for the purposes + of computing the digest. + + o Its authSrcTimestamp component is called the + authentication timestamp and represents the time of the + generation of the message according to the partyAuthClock + of the SNMPv2 party that originated it. Note that the + granularity of the authentication timestamp is 1 second. + + o Its authDstTimestamp component is called the + authentication timestamp and represents the time of the + generation of the message according to the partyAuthClock + of the SNMPv2 party that is to receive it. Note that the + granularity of the authentication timestamp is 1 second. + + + 3.1. Generating a Message + + This section describes the behavior of a SNMPv2 entity when it + acts as a SNMPv2 party for which the authentication protocol + is administratively specified as the Digest Authentication + Protocol. Insofar as the behavior of a SNMPv2 entity when + transmitting protocol messages is defined generically in [1], + only those aspects of that behavior that are specific to the + Digest Authentication Protocol are described below. In + + + + + + Galvin & McCloghrie [Page 16] + + + + + + RFC 1446 Security Protocols for SNMPv2 April 1993 + + + particular, this section describes the encapsulation of a + SNMPv2 management communication into a SNMPv2 authenticated + management communication. + + According to Section 3.1 of [1], a SnmpAuthMsg value is + constructed during Step 3 of generic processing. In + particular, it states the authInfo component is constructed + according to the authentication protocol identified for the + SNMPv2 party originating the message. When the relevant + authentication protocol is the Digest Authentication Protocol, + the procedure performed by a SNMPv2 entity whenever a + management communication is to be transmitted by a SNMPv2 + party is as follows. + + (1) The local database is consulted to determine the + authentication clock and private authentication key + (extracted, for example, according to the conventions + defined in Section 1.5.1) of the SNMPv2 party originating + the message. The local database is also consulted to + determine the authentication clock of the receiving + SNMPv2 party. + + (2) The authSrcTimestamp component is set to the retrieved + authentication clock value of the message's source. The + authDstTimestamp component is set to the retrieved + authentication clock value of the message's intended + recipient. + + (3) The authentication digest is temporarily set to the + private authentication key of the SNMPv2 party + originating the message. The SnmpAuthMsg value is + serialized according to the conventions of [13] and [12]. + A digest is computed over the octet sequence representing + that serialized value using, for example, the algorithm + specified in Section 1.5.1. The authDigest component is + set to the computed digest value. + + As set forth in [1], the SnmpAuthMsg value is then + encapsulated according to the appropriate privacy protocol + into a SnmpPrivMsg value. This latter value is then + serialized and transmitted to the receiving SNMPv2 party. + + + + + + + + + + Galvin & McCloghrie [Page 17] + + + + + + RFC 1446 Security Protocols for SNMPv2 April 1993 + + + 3.2. Receiving a Message + + This section describes the behavior of a SNMPv2 entity upon + receipt of a protocol message from a SNMPv2 party for which + the authentication protocol is administratively specified as + the Digest Authentication Protocol. Insofar as the behavior + of a SNMPv2 entity when receiving protocol messages is defined + generically in [1], only those aspects of that behavior that + are specific to the Digest Authentication Protocol are + described below. + + According to Section 3.2 of [1], a SnmpAuthMsg value is + evaluated during Step 9 of generic processing. In particular, + it states the SnmpAuthMsg value is evaluated according to the + authentication protocol identified for the SNMPv2 party that + originated the message. When the relevant authentication + protocol is the Digest Authentication Protocol, the procedure + performed by a SNMPv2 entity whenever a management + communication is received by a SNMPv2 party is as follows. + + (1) If the ASN.1 type of the authInfo component is not + AuthInformation, the message is evaluated as unauthentic, + and the snmpStatsBadAuths counter [14] is incremented. + Otherwise, the authSrcTimestamp, authDstTimestamp, and + authDigest components are extracted from the SnmpAuthMsg + value. + + (2) The local database is consulted to determine the + authentication clock, private authentication key + (extracted, for example, according to the conventions + defined in Section 1.5.1), and lifetime of the SNMPv2 + party that originated the message. + + (3) If the authSrcTimestamp component plus the lifetime is + less than the authentication clock, the message is + evaluated as unauthentic, and the snmpStatsNotInLifetimes + counter [14] is incremented. + + (4) The authDigest component is extracted and temporarily + recorded. + + (5) A new SnmpAuthMsg value is constructed such that its + authDigest component is set to the private authentication + key and its other components are set to the value of the + corresponding components in the received SnmpAuthMsg + + + + + + Galvin & McCloghrie [Page 18] + + + + + + RFC 1446 Security Protocols for SNMPv2 April 1993 + + + value. This new SnmpAuthMsg value is serialized + according to the conventions of [13] and [12]. A digest + is computed over the octet sequence representing that + serialized value using, for example, the algorithm + specified in Section 1.5.1. + + NOTE + Because serialization rules are unambiguous but may + not be unique, great care must be taken in + reconstructing the serialized value prior to + computing the digest. Implementations may find it + useful to keep a copy of the original serialized + value and then simply modify the octets which + directly correspond to the placement of the + authDigest component, rather than re-applying the + serialization algorithm to the new SnmpAuthMsg + value. + + (6) If the computed digest value is not equal to the digest + value temporarily recorded in step 4 above, the message + is evaluated as unauthentic, and the + snmpStatsWrongDigestValues counter [14] is incremented. + + (7) The message is evaluated as authentic. + + (8) The local database is consulted for access privileges + permitted by the local access policy to the originating + SNMPv2 party with respect to the receiving SNMPv2 party. + If any level of access is permitted, then: + + the authentication clock value locally recorded for the + originating SNMPv2 party is advanced to the + authSrcTimestamp value if this latter exceeds the + recorded value; and, + + the authentication clock value locally recorded for the + receiving SNMPv2 party is advanced to the + authDstTimestamp value if this latter exceeds the + recorded value. + + (Note that this step is conceptually independent from + Steps 15-17 of Section 3.2 in [1]). + + If the SnmpAuthMsg value is evaluated as unauthentic, an + authentication failure is noted and the received message is + + + + + + Galvin & McCloghrie [Page 19] + + + + + + RFC 1446 Security Protocols for SNMPv2 April 1993 + + + discarded without further processing. Otherwise, processing + of the received message continues as specified in [1]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Galvin & McCloghrie [Page 20] + + + + + + RFC 1446 Security Protocols for SNMPv2 April 1993 + + + 4. Symmetric Privacy Protocol + + This section describes the Symmetric Privacy Protocol. It + provides for protection from disclosure of a received message. + An appropriate portion of the message is encrypted according + to a secret key known only to the originator and recipient of + the message. + + This protocol assumes the underlying mechanism is a symmetric + encryption algorithm. In addition, the message to be + encrypted must be protected according to the conventions of + the Digest Authentication Protocol. + + Recall from [1] that a SNMPv2 private management communication + is represented by an ASN.1 value with the following syntax: + + SnmpPrivMsg ::= [1] IMPLICIT SEQUENCE { + privDst + OBJECT IDENTIFIER, + privData + [1] IMPLICIT OCTET STRING + } + + For each SnmpPrivMsg value that represents a SNMPv2 private + management communication, the following statements are true: + + o Its privDst component is called the privacy destination + and identifies the SNMPv2 party to which the + communication is directed. + + o Its privData component is called the privacy data and + represents the (possibly encrypted) serialization + (according to the conventions of [13] and [12]) of a + SNMPv2 authenticated management communication. + + + 4.1. Generating a Message + + This section describes the behavior of a SNMPv2 entity when it + communicates with a SNMPv2 party for which the privacy + protocol is administratively specified as the Symmetric + Privacy Protocol. Insofar as the behavior of a SNMPv2 entity + when transmitting a protocol message is defined generically in + [1], only those aspects of that behavior that are specific to + the Symmetric Privacy Protocol are described below. In + + + + + + Galvin & McCloghrie [Page 21] + + + + + + RFC 1446 Security Protocols for SNMPv2 April 1993 + + + particular, this section describes the encapsulation of a + SNMPv2 authenticated management communication into a SNMPv2 + private management communication. + + According to Section 3.1 of [1], a SnmpPrivMsg value is + constructed during Step 5 of generic processing. In + particular, it states the privData component is constructed + according to the privacy protocol identified for the SNMPv2 + party receiving the message. When the relevant privacy + protocol is the Symmetric Privacy Protocol, the procedure + performed by a SNMPv2 entity whenever a management + communication is to be transmitted by a SNMPv2 party is as + follows. + + (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 SNMPv2 party receiving the message + (represented, for example, according to the conventions + defined in Section 1.5.2). + + (3) The SnmpAuthMsg value is serialized according to the + conventions of [13] and [12]. + + (4) The octet sequence representing the serialized + SnmpAuthMsg value is encrypted using, for example, the + algorithm specified in Section 1.5.2 and the extracted + private privacy key. + + (5) The privData component is set to the encrypted value. + + As set forth in [1], the SnmpPrivMsg value is then serialized + and transmitted to the receiving SNMPv2 party. + + + 4.2. Receiving a Message + + This section describes the behavior of a SNMPv2 entity when it + acts as a SNMPv2 party for which the privacy protocol is + administratively specified as the Symmetric Privacy Protocol. + Insofar as the behavior of a SNMPv2 entity when receiving a + + + + + + Galvin & McCloghrie [Page 22] + + + + + + RFC 1446 Security Protocols for SNMPv2 April 1993 + + + protocol message is defined generically in [1], only those + aspects of that behavior that are specific to the Symmetric + Privacy Protocol are described below. + + According to Section 3.2 of [1], the privData component of a + received SnmpPrivMsg value is evaluated during Step 4 of + generic processing. In particular, it states the privData + component is evaluated according to the privacy protocol + identified for the SNMPv2 party receiving the message. When + the relevant privacy protocol is the Symmetric Privacy + Protocol, the procedure performed by a SNMPv2 entity whenever + a management communication is received by a SNMPv2 party is as + follows. + + (1) The local database is consulted to determine the private + privacy key of the SNMPv2 party receiving the message + (represented, for example, according to the conventions + defined in Section 1.5.2). + + (2) The contents octets of the privData component are + decrypted using, for example, the algorithm specified in + Section 1.5.2 and the extracted private privacy key. + + Processing of the received message continues as specified in + [1]. + + + + + + + + + + + + + + + + + + + + + + + + + + Galvin & McCloghrie [Page 23] + + + + + + RFC 1446 Security Protocols for SNMPv2 April 1993 + + + 5. Clock and Secret Distribution + + The protocols described in Sections 3 and 4 assume the + existence of loosely synchronized clocks and shared secret + values. Three requirements constrain the strategy by which + clock values and secrets are distributed. + + o If the value of an authentication clock is decreased, the + private authentication key must be changed concurrently. + + When the value of an authentication clock is decreased, + messages that have been sent with a timestamp value + between the value of the authentication clock and its new + value may be replayed. Changing the private + authentication key obviates this threat. + + o The private authentication key and private privacy key + must be known only to the parties requiring knowledge of + them. + + Protecting the secrets from disclosure is critical to the + security of the protocols. Knowledge of the secrets must + be as restricted as possible within an implementation. + In particular, 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 such that their actual value is known only + to the software. A management station has the additional + responsibility of recovering the state of all parties + whenever it boots, and it may address this responsibility + by recording the secrets on a long-term storage device. + Access to information on this device must be as + restricted as is practically possible. + + o There must exist at least one SNMPv2 entity that assumes + the role of a responsible management station. + + This management station is responsible for ensuring that + all authentication clocks are synchronized and for + changing the secret values when necessary. Although more + than one management station may share this + responsibility, their coordination is essential to the + secure management of the network. The mechanism by which + multiple management stations ensure that no more than one + of them attempts to synchronize the clocks or update the + + + + + + Galvin & McCloghrie [Page 24] + + + + + + RFC 1446 Security Protocols for SNMPv2 April 1993 + + + 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 by which a + SNMPv2 entity is initially configured. The next two sections + describe one strategy for distributing clock values and one + for determining a synchronized clock value among SNMPv2 + parties supporting the Digest Authentication Protocol. For + SNMPv2 parties supporting the Symmetric Privacy Protocol, the + next section describes a strategy for distributing secret + values. The last section specifies the procedures by which a + SNMPv2 entity recovers from a "crash." + + + 5.1. Initial Configuration + + This section describes the initial configuration of a SNMPv2 + entity that supports the Digest Authentication Protocol or + both the Digest Authentication Protocol and the Symmetric + Privacy Protocol. + + When a network device is first installed, its initial, secure + configuration must be done manually, i.e., a person must + physically visit the device and enter the initial secret + values for at least its first secure SNMPv2 party. This + requirement suggests that the person will have knowledge of + the initial secret values. + + In general, the security of a system is enhanced as the number + of entities that know a secret is reduced. Requiring a person + to physically visit a device every time a SNMPv2 party is + configured not only exposes the secrets unnecessarily but is + administratively prohibitive. In particular, 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 will need to be recorded on a medium in order to be + transported between a responsible management station and a + managed agent. The recommended procedure is to configure a + small set of initial SNMPv2 parties for each SNMPv2 entity, + one pair of which may be used initially to configure all other + SNMPv2 parties. + + + + + + Galvin & McCloghrie [Page 25] + + + + + + RFC 1446 Security Protocols for SNMPv2 April 1993 + + + In fact, there is a minimal, useful set of SNMPv2 parties that + could be configured between each responsible management + station and managed agent. This minimal set includes one of + each of the following for both the responsible management + station and the managed agent: + + o a SNMPv2 party for which the authentication protocol and + privacy protocol are the values noAuth and noPriv, + respectively, + + o a SNMPv2 party for which the authentication protocol + identifies the mechanism defined in Section 1.5.1 and its + privacy protocol is the value noPriv, and + + o a SNMPv2 party for which the authentication protocol and + privacy protocol identify the mechanisms defined in + Section 1.5.1 and Section 1.5.2, respectively. + + The last of these SNMPv2 parties in both the responsible + management station and the managed agent could be used to + create all other SNMPv2 parties. + + Configuring one pair of SNMPv2 parties to be used to configure + all other parties has the advantage of exposing only one pair + of secrets - the secrets used to configure the minimal, useful + set identified above. To limit this exposure, the responsible + management station should change these values as its first + operation upon completion of the initial configuration. In + this way, secrets are known only to the peers requiring + knowledge of 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. + + These 6 initial parties are required to exist as part of the + configuration of implementations when first installed, with + the exception that implementations not providing support for a + privacy protocol only need the 4 initial parties for which the + privacy protocol is noPriv. When installing a managed agent, + these parties need to be configured with their initial + secrets, etc., both in the responsible management station and + in the new agent. + + + + + + + Galvin & McCloghrie [Page 26] + + + + + + RFC 1446 Security Protocols for SNMPv2 April 1993 + + + If the responsible management station is configured first, it + can be used to generate the initial secrets and provide them + to a person, on a suitable medium, for distribution to the + managed agent. The following sequence of steps describes the + initial configuration of a managed agent and its responsible + management station. + + (1) Determine the initial values for each of the attributes + of the SNMPv2 party to be configured. Some of these + values may be computed by the responsible management + station, some may be specified in the MIB document, and + some may be administratively determined. + + (2) Configure the parties in the responsible management + station, according to the set of initial values. If the + management station is computing some initial values to be + entered into the agent, an appropriate medium must be + present to record the values. + + (3) Configure the parties in the managed agent, according to + the set of initial values. + + (4) The responsible management station must synchronize the + authentication clock values for each party it shares with + each managed agent. Section 5.3 specifies one strategy + by which this could be accomplished. + + (5) The responsible management station should change the + secret values manually configured to ensure the actual + values are known only to the peers requiring knowledge of + them in order to communicate. To do this, the management + station generates new secrets for each party to be + reconfigured and distributes the updates using any + strategy which protects the new values from disclosure; + use of a SNMPv2 set operation acting on the managed + objects defined in [4] is such a strategy. Upon + receiving positive acknowledgement that the new values + have been distributed, the management station should + update its local database with the new values. + + If the managed agent does not support a protocol that protects + messages from disclosure, e.g., the Symmetric Privacy Protocol + (see section 5.4), then the distribution of new secrets, after + the compromise of existing secrets, is not possible. In this + case, the new secrets can only be distributed by a physical + + + + + + Galvin & McCloghrie [Page 27] + + + + + + RFC 1446 Security Protocols for SNMPv2 April 1993 + + + visit to the device. + + If there are other SNMPv2 protocol entities requiring + knowledge of the secrets, the responsible management station + must distribute the information upon completion of the initial + configuration. The considerations, mentioned above, + concerning the protection of secrets from disclosure, also + apply in this case. + + + 5.2. Clock Distribution + + A responsible management station must ensure that the + authentication clock value for each SNMPv2 party for which it + is responsible + + o is loosely synchronized among all the local databases in + which it appears, + + o is reset, as indicated below, upon reaching its maximal + value, and + + o 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 by a number of + strategies, including knowledge of the accuracy of the system + clock, unauthenticated queries of the party database, and + recognition of authentication failures originated by the + party. + + Whenever clock skew is detected, and whenever the SNMPv2 + entities at both the responsible management station and the + relevant managed agent support an appropriate privacy protocol + (e.g., the Symmetric Privacy Protocol), a straightforward + strategy for the correction of clock skew is simultaneous + alteration of authentication clock and private key for the + relevant SNMPv2 party. If the request to alter the key and + clock for a particular party originates from that same party, + then, prior to transmitting that request, the local notion of + the authentication clock is artificially advanced to assure + acceptance of the request as authentic. + + + + + + Galvin & McCloghrie [Page 28] + + + + + + RFC 1446 Security Protocols for SNMPv2 April 1993 + + + More generally, however, since an authentication clock value + need not be protected from disclosure, it is not necessary + that a managed agent support a privacy protocol in order for a + responsible management station to correct skewed clock values. + The procedure for correcting clock skew in the general case is + presented in Section 5.3. + + In addition to correcting skewed notions of authentication + clocks, every SNMPv2 entity must react correctly as an + authentication clock approaches its maximal value. If the + authentication clock for a particular SNMPv2 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 SNMPv2 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. In order to reset these values, the responsible + management station may set the authentication timestamp in the + message to the maximal time value. + + The value of the authentication clock for a particular SNMPv2 + party must never be altered such that its new value is less + than its old value, unless its private authentication key is + also altered at the same time. + + + 5.3. Clock Synchronization + + Unless the secrets are changed at the same time, the correct + way to synchronize clocks is to advance the slower clock to be + equal to the faster clock. Suppose that party agentParty is + realized by the SNMPv2 entity in a managed agent; suppose that + party mgrParty is realized by the SNMPv2 entity in the + corresponding responsible management station. For any pair of + parties, there are four possible conditions of the + authentication clocks that could require correction: + + (1) The management station's notion of the value of the + authentication clock for agentParty exceeds the agent's + notion. + + + + + + + Galvin & McCloghrie [Page 29] + + + + + + RFC 1446 Security Protocols for SNMPv2 April 1993 + + + (2) The management station's notion of the value of the + authentication clock for mgrParty exceeds the agent's + notion. + + (3) The agent's notion of the value of the authentication + clock for agentParty exceeds the management station's + notion. + + (4) The agent's notion of the value of the authentication + clock for mgrParty exceeds the management station's + notion. + + The selective clock acceleration mechanism intrinsic to the + protocol corrects conditions 1, 2 and 3 as part of the normal + processing of an authentic message. Therefore, the clock + adjustment procedure below does not provide for any + adjustments in those cases. Rather, the following sequence of + steps specifies how the clocks may be synchronized when + condition 4 is manifest. + + (1) The responsible management station saves its existing + notion of the authentication clock for the party + mgrParty. + + (2) The responsible management station retrieves the + authentication clock value for mgrParty from the agent. + This retrieval must be an unauthenticated request, since + the management station does not know if the clocks are + synchronized. If the request fails, the clocks cannot be + synchronized, and the clock adjustment procedure is + aborted without further processing. + + (3) If the notion of the authentication clock for mgrParty + just retrieved from the agent exceeds the management + station's notion, then condition 4 is manifest, and the + responsible management station advances its notion of the + authentication clock for mgrParty to match the agent's + notion. + + (4) The responsible management station retrieves the + authentication clock value for mgrParty from the agent. + This retrieval must be an authenticated request, in order + that the management station may verify that the clock + value is properly synchronized. If this authenticated + query fails, then the management station restores its + + + + + + Galvin & McCloghrie [Page 30] + + + + + + RFC 1446 Security Protocols for SNMPv2 April 1993 + + + previously saved notion of the clock value, and the clock + adjustment procedure is aborted without further + processing. Otherwise, clock synchronization has been + successfully realized. + + Administrative advancement of a clock as described above does + not introduce any new vulnerabilities, since the value of the + clock is intended to increase with the passage of time. A + potential operational problem is the rejection of authentic + management operations that were 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. + + + 5.4. Secret Distribution + + This section describes one strategy by which a SNMPv2 entity + that supports both the Digest Authentication Protocol and the + Symmetric Privacy Protocol can change the secrets for a + particular SNMPv2 party. + + The frequency with which the secrets of a SNMPv2 party should + be changed is a local administrative issue. However, the more + frequently a secret is used, the more frequently it should be + changed. At a minimum, the secrets must be changed whenever + the associated authentication clock approaches its maximal + value (see Section 6). Note that, owing to both + administrative and automatic advances of the authentication + clock described in this memo, the authentication clock for a + SNMPv2 party may well approach its maximal value sooner than + 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 SNMPv2 party. There are two cases. + + First, setting the initial secret for a new party: + + (1) The responsible management station generates a new secret + value. + + + + + + + + Galvin & McCloghrie [Page 31] + + + + + + RFC 1446 Security Protocols for SNMPv2 April 1993 + + + (2) The responsible management station encapsulates a SNMPv2 + setRequest in a SNMPv2 private management communication + with at least the following properties. + + Its source supports the Digest Authentication + Protocol and the Symmetric Privacy Protocol. + + Its destination supports the Symmetric Privacy + Protocol and the Digest Authentication Protocol. + + (3) The SNMPv2 private management communication is + transmitted to its destination. + + (4) Upon receiving the request, the recipient processes the + message according to [12] and [1]. + + (5) The recipient encapsulates a SNMPv2 response in a SNMPv2 + private management communication with at least the + following properties. + + Its source supports the Digest Authentication + Protocol and the Symmetric Privacy Protocol. + + Its destination supports the Symmetric Privacy + Protocol and the Digest Authentication Protocol. + + (6) The SNMPv2 private management communication is + transmitted to its destination. + + (7) Upon receiving the response, the responsible management + station updates its local database with the new value. + + Second, modifying the current secret of an existing party: + + (1) The responsible management station generates a new secret + value. + + (2) The responsible management station encapsulates a SNMPv2 + setRequest in a SNMPv2 management communication with at + least the following properties. + + Its source and destination supports the Digest + Authentication Protocol. + + + + + + + + Galvin & McCloghrie [Page 32] + + + + + + RFC 1446 Security Protocols for SNMPv2 April 1993 + + + (3) The SNMPv2 private management communication is + transmitted to its destination. + + (4) Upon receiving the request, the recipient processes the + message according to [12] and [1]. + + (5) The recipient encapsulates a SNMPv2 response in a SNMPv2 + management communication with at least the following + properties. + + Its source and destination supports the Digest + Authentication Protocol. + + (6) The SNMPv2 management communication is transmitted to its + destination. + + (7) Upon receiving the response, the responsible management + station updates its local database with the new value. + + If the responsible management station does not receive a + response to its request, there are two possible causes. + + o The request may not have been delivered to the + destination. + + o The response may not have been delivered to the + originator of the request. + + In order to distinguish the two possible error conditions, a + responsible management station could check the destination to + see if the change has occurred. Unfortunately, since the + secret values are unreadable, this is not directly possible. + + The recommended strategy for verifying key changes is to set + the public value corresponding to the secret being changed to + a recognizable, novel value: that is, alter the public + authentication key value for the relevant party when changing + its private authentication key, or alter its public privacy + key value when changing its private privacy key. In this way, + the responsible management station may retrieve the public + value when a response is not received, and verify whether or + not the change has taken place. (This strategy is available + since the public values are not used by the protocols defined + in this memo. If this strategy is employed, then the public + values are significant in this context. Of course, protocols + + + + + + Galvin & McCloghrie [Page 33] + + + + + + RFC 1446 Security Protocols for SNMPv2 April 1993 + + + using the public values may make use of this strategy + directly.) + + One other scenario worthy of mention is using a SNMPv2 party + to change its own secrets. In this case, the destination will + change its local database prior to generating a response. + Thus, the response will be constructed according to the new + value. However, the responsible management station will not + update its local database until after the response is + received. This suggests the responsible management station + may receive a response which will be evaluated as unauthentic, + unless the correct secret is used. The responsible management + station may either account for this scenario as a special + case, or use an alteration of the relevant public values (as + described above) to verify the key change. + + Note, during the period of time after the request has been + sent and before the response is received, the management + station must keep track of both the old and new secret values. + Since the delay may be the result of a network failure, the + management station must be prepared to retain both values for + an extended period of time, including across reboots. + + + 5.5. Crash Recovery + + This section describes the requirements for SNMPv2 protocol + entities in connection with recovery from system crashes or + other service interruptions. + + For each SNMPv2 party in the local database for a particular + SNMPv2 entity, its identity, authentication clock, private + authentication key, and private privacy key must enjoy non- + volatile, incorruptible representations. If possible, + lifetime should also enjoy a non-volatile, incorruptible + representation. If said SNMPv2 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 SNMPv2 party is a critical + component of the overall security of the protocols. The + inclusion of a reliable representation of a clock in a SNMPv2 + entity is required for overall security. A reliable clock + + + + + + Galvin & McCloghrie [Page 34] + + + + + + RFC 1446 Security Protocols for SNMPv2 April 1993 + + + representation ensures that a clock's value is monotonically + increasing, even across a power loss or other system failure + of the local SNMPv2 entity. One example of a reliable clock + representation is that provided by battery-powered clock- + calendar devices incorporated into some contemporary systems. + Another example is storing and updating a clock value in non- + volatile storage at a frequency of once per U (e.g., 24) + hours, and re-initialising that clock value on every reboot as + the stored value plus U+1 hours. It is assumed that + management stations always support reliable clock + representations, where clock adjustment by a human operator + during crash recovery may contribute to that reliability. + + If a managed agent crashes and does not reboot in time for its + responsible management station to prevent its authentication + clock from reaching its maximal value, upon reboot the clock + must be halted at its maximal value. The procedures specified + in Section 5.3 would then apply. + + Upon recovery, those attributes of each SNMPv2 party that do + not enjoy non-volatile or reliable representation are + initialized as follows. + + o If the private authentication key is not the OCTET STRING + of zero length, the authentication protocol is set to + identify use of the Digest Authentication Protocol in + conjunction with the algorithm specified in Section + 1.5.1. + + o If the lifetime is not retained, it should be initialized + to zero. + + o If the private privacy key is not the OCTET STRING of + zero length, the privacy protocol is set to identify use + of the Symmetric Privacy Protocol in conjunction with the + algorithm specified in Section 1.5.2. + + Upon detecting that a managed agent has rebooted, a + responsible management station must reset all other party + attributes, including the lifetime if it was not retained. In + order to reset the lifetime, the responsible management + station should set the authentication timestamp in the message + to the sum of the authentication clock and desired lifetime. + This is an artificial advancement of the authentication + timestamp in order to guarantee the message will be authentic + + + + + + Galvin & McCloghrie [Page 35] + + + + + + RFC 1446 Security Protocols for SNMPv2 April 1993 + + + when received by the recipient. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Galvin & McCloghrie [Page 36] + + + + + + RFC 1446 Security Protocols for SNMPv2 April 1993 + + + 6. Security Considerations + + This section highlights security considerations relevant to + the protocols and procedures defined in this memo. Practices + that contribute to secure, effective operation of the + mechanisms defined here are described first. Constraints on + implementation behavior that are necessary to the security of + the system are presented next. Finally, an informal account + of the contribution of each mechanism of the protocols to the + required goals is presented. + + + 6.1. Recommended Practices + + This section describes practices that contribute to the + secure, effective operation of the mechanisms defined in this + memo. + + o A management station should discard SNMPv2 responses for + which neither the request-id component nor the + represented management information corresponds to any + currently outstanding request. + + Although it would be typical for a management station to + do this as a matter of course, in the context of these + security protocols it is significant owing to the + possibility of message duplication (malicious or + otherwise). + + o A management station should not interpret an agent's lack + of response to an authenticated SNMPv2 management + communication as a conclusive indication of agent or + network failure. + + It is possible for authentication failure traps to be + lost or suppressed as a result of authentication clock + skew or inconsistent notions of shared secrets. In order + either to facilitate administration of such SNMPv2 + parties or to provide for continued management in times + of network stress, a management station implementation + may provide for arbitrary, artificial advancement of the + timestamp or selection of shared secrets on locally + generated messages. + + + + + + + + Galvin & McCloghrie [Page 37] + + + + + + RFC 1446 Security Protocols for SNMPv2 April 1993 + + + o The lifetime value for a SNMPv2 party should be chosen + (by the local administration) to be as small as possible, + given the accuracy of clock devices available, relevant + round-trip communications delays, and the frequency with + which a responsible management station will be able to + verify all clock values. + + A large lifetime increases the vulnerability to malicious + delays of SNMPv2 messages. The implementation of a + management station may accommodate changing network + conditions during periods of network stress by + effectively increasing the lifetimes of the source and + destination parties. The management station accomplishes + this by artificially advancing its notion of the source + party's clock on messages it sends, and by artificially + increasing its notion of the source party`s lifetime on + messages it receives. + + o When sending state altering messages to a managed agent, + a management station should delay sending successive + messages to the managed agent until a positive + acknowledgement is received for the previous message or + until the previous message expires. + + No message ordering is imposed by the SNMPv2. Messages + may be received in any order relative to their time of + generation and each will be processed in the ordered + received. Note that when an authenticated message is + sent to a managed agent, it will be valid for a period of + time that does not exceed lifetime under normal + circumstances, and is subject to replay during this + period. + + Indeed, a management station must cope with the loss and + re-ordering of messages resulting from anomalies in the + network as a matter of course. + + However, a managed object, snmpSetSerialNo [14], is + specifically defined for use with SNMPv2 set operations + in order to provide a mechanism to ensure the processing + of SNMPv2 messages occurs in a specific order. + + o The frequency with which the secrets of a SNMPv2 party + should be changed is indirectly related to the frequency + of their use. + + + + + + Galvin & McCloghrie [Page 38] + + + + + + RFC 1446 Security Protocols for SNMPv2 April 1993 + + + Protecting the secrets from disclosure is critical to the + overall security of the protocols. Frequent use of a + secret provides a continued source of data that may be + useful to a cryptanalyst in exploiting known or perceived + weaknesses in an algorithm. Frequent changes to the + secret avoid this vulnerability. + + Changing a secret after each use is generally regarded as + the most secure practice, but a significant amount of + overhead may be associated with that approach. + + Note, too, in a local environment the threat of + disclosure may be insignificant, and as such the changing + of secrets may be less frequent. However, when public + data networks are the communication paths, more caution + is prudent. + + o In order to foster the greatest degree of security, a + management station implementation must support + constrained, pairwise sharing of secrets among SNMPv2 + entities as its default mode of operation. + + Owing to the use of symmetric cryptography in the + protocols defined here, the secrets associated with a + particular SNMPv2 party must be known to all other SNMPv2 + parties with which that party may wish to communicate. + As the number of locations at which secrets are known and + used increases, the likelihood of their disclosure also + increases, as does the potential impact of that + disclosure. Moreover, if the set of SNMPv2 protocol + entities with knowledge of a particular secret numbers + more than two, data origin cannot be reliably + authenticated because it is impossible to determine with + any assurance which entity of that set may be the + originator of a particular SNMPv2 message. Thus, the + greatest degree of security is afforded by configurations + in which the secrets for each SNMPv2 party are known to + at most two protocol entities. + + + 6.2. Conformance + + A SNMPv2 entity implementation that claims conformance to this + memo must satisfy the following requirements: + + + + + + + Galvin & McCloghrie [Page 39] + + + + + + RFC 1446 Security Protocols for SNMPv2 April 1993 + + + (1) It must implement the noAuth and noPriv protocols whose + object identifiers are defined in [4]. + + noAuth This protocol signifies that messages + generated by a party using it are not protected as + to origin or integrity. It is required to ensure + that a party's authentication clock is always + accessible. + + noPriv This protocol signifies that messages + received by a party using it are not protected from + disclosure. It is required to ensure that a party's + authentication clock is always accessible. + + (2) It must implement the Digest Authentication Protocol in + conjunction with the algorithm defined in Section 1.5.1. + + (3) It must include in its local database at least one SNMPv2 + party with the following parameters set as follows: + + partyAuthProtocol is set to noAuth and + + partyPrivProtocol is set to noPriv. + + This party must have a MIB view [1] specified that + includes at least the authentication clock of all other + parties. Alternatively, the authentication clocks of the + other parties may be partitioned among several similarly + configured parties according to a local implementation + convention. + + (4) For each SNMPv2 party about which it maintains + 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 1.4 specifies constraints for + the chosen mechanisms. + + (b) It must, to the maximal extent possible, + prohibit read-access to the private authentication + key and private encryption key under all + circumstances except as required to generate and/or + validate SNMPv2 messages with respect to that party. + + + + + + Galvin & McCloghrie [Page 40] + + + + + + RFC 1446 Security Protocols for SNMPv2 April 1993 + + + This prohibition includes prevention of read-access + by the entity's human operators. + + (c) It must allow the party's authentication clock + to be publicly accessible. The correct operation of + the Digest Authentication Protocol requires that it + be possible to determine this value at all times in + order to guarantee 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. + + (5) If it selects new value(s) for a party's secret(s), it + must avoid bad or obvious choices for said secret(s). + Choices to be avoided are boundary values (such as all- + zeros) and predictable values (such as the same value as + previously or selecting from a predetermined set). + + (6) It must ensure that a received message for which the + originating party uses the Digest Authentication Protocol + but the receiving party does not, is always declared to + + + + + + Galvin & McCloghrie [Page 41] + + + + + + RFC 1446 Security Protocols for SNMPv2 April 1993 + + + be unauthentic. This may be achieved explicitly via an + additional step in the procedure for processing a + received message, or implicitly by verifying that all + local access control policies enforce this requirement. + + + 6.3. Protocol Correctness + + The correctness of these SNMPv2 security protocols with + respect to the stated goals depends on the following + assumptions: + + (1) The chosen message digest algorithm satisfies its design + criteria. In particular, it must be computationally + infeasible to discover two messages that share the same + digest value. + + (2) It is computationally infeasible to determine the secret + used in calculating a digest on the concatenation of the + secret and a message when both the digest and the message + are known. + + (3) The chosen symmetric encryption algorithm satisfies its + design criteria. In particular, it must be + computationally infeasible to determine the cleartext + message from the ciphertext message without knowledge of + the key used in the transformation. + + (4) Local notions of a party's authentication clock while it + is associated with a specific private key value are + monotonically non-decreasing (i.e., they never run + backwards) in the absence of administrative + manipulations. + + (5) The secrets for a particular SNMPv2 party are known only + to authorized SNMPv2 protocol entities. + + (6) Local notions of the authentication clock for a + particular SNMPv2 party are never altered such that the + authentication clock's new value is less than the current + value without also altering the private authentication + key. + + For each mechanism of the protocol, an informal account of its + contribution to the required goals is presented below. + + + + + + Galvin & McCloghrie [Page 42] + + + + + + RFC 1446 Security Protocols for SNMPv2 April 1993 + + + Pseudocode fragments are provided where appropriate to + exemplify possible implementations; they are intended to be + self-explanatory. + + + 6.3.1. Clock Monotonicity Mechanism + + By pairing each sequence of a clock's values with a unique + key, the protocols partially realize goal 3, and the + conjunction of this property with assumption 6 above is + sufficient for the claim that, with respect to a specific + private key value, all local notions of a party's + authentication clock are, in general, non-decreasing with + time. + + + 6.3.2. Data Integrity Mechanism + + The protocols require computation of a message digest computed + over the SNMPv2 message prepended by the secret for the + relevant party. By virtue of this mechanism and assumptions 1 + and 2, the protocols realize goal 1. + + Normally, the inclusion of the message digest value with the + digested message would not be sufficient to guarantee data + integrity, since the digest value can be modified in addition + to the message while it is enroute. However, since not all of + the digested message is included in the transmission to the + destination, it is not possible to substitute both a message + and a digest value while enroute to a destination. + + Strictly speaking, the specified strategy for data integrity + does not detect a SNMPv2 message modification which appends + extraneous material to the end of such messages. However, + owing to the representation of SNMPv2 messages as ASN.1 + values, such modifications cannot - consistent with goal 1 - + result in unauthorized management operations. + + The data integrity mechanism specified in this memo protects + only against unauthorized modification of individual SNMPv2 + messages. A more general data integrity service that affords + protection against the threat of message stream modification + is not realized by this mechanism, although limited protection + against reordering, delay, and duplication of messages within + a message stream are provided by other mechanisms of the + + + + + + Galvin & McCloghrie [Page 43] + + + + + + RFC 1446 Security Protocols for SNMPv2 April 1993 + + + protocol. + + + 6.3.3. Data Origin Authentication Mechanism + + The data integrity mechanism requires the use of a secret + value known only to communicating parties. By virtue of this + mechanism and assumptions 1 and 2, the protocols explicitly + prevent unauthorized modification of messages. Data origin + authentication is implicit if the message digest value can be + verified. That is, the protocols realize goal 2. + + + 6.3.4. Restricted Administration Mechanism + + This memo requires that implementations preclude + administrative alterations of the authentication clock for a + particular party independently from its private authentication + key (unless that clock alteration is an advancement). An + example of an efficient implementation of this restriction is + provided in a pseudocode fragment below. This pseudocode + fragment meets the requirements of assumption 6. Observe that + the requirement is not for simultaneous alteration but to + preclude independent alteration. This latter requirement is + fairly easily realized in a way that is consistent with the + defined semantics of the SNMPv2 set operation. + + + + + + + + + + + + + + + + + + + + + + + + + Galvin & McCloghrie [Page 44] + + + + + + RFC 1446 Security Protocols for SNMPv2 April 1993 + + + Void partySetKey (party, newKeyValue) + { + if (party->clockAltered) { + party->clockAltered = FALSE; + party->keyAltered = FALSE; + party->keyInUse = newKeyValue; + party->clockInUse = party->clockCache; + } + else { + party->keyAltered = TRUE; + party->keyCache = newKeyValue; + } + } + + Void partySetClock (party, newClockValue) + { + if (party->keyAltered) { + party->keyAltered = FALSE; + party->clockAltered = FALSE; + party->clockInUse = newClockValue; + party->keyInUse = party->keyCache; + } + else { + party->clockAltered = TRUE; + party->clockCache = newClockValue; + } + } + + + 6.3.5. Message Timeliness Mechanism + + The definition of the SNMPv2 security protocols requires that, + if the authentication timestamp value on a received message - + augmented by an administratively chosen lifetime value - is + less than the local notion of the clock for the originating + SNMPv2 party, the message is not delivered. + + + if (timestampOfReceivedMsg + + party->administrativeLifetime <= + party->localNotionOfClock) { + msgIsValidated = FALSE; + } + + + + + + + + Galvin & McCloghrie [Page 45] + + + + + + RFC 1446 Security Protocols for SNMPv2 April 1993 + + + By virtue of this mechanism, the protocols realize goal 3. In + cases in which the local notions of a particular SNMPv2 party + clock are moderately well-synchronized, the timeliness + mechanism effectively limits the age of validly delivered + messages. Thus, if an attacker diverts all validated messages + for replay much later, the delay introduced by this attack is + limited to a period that is proportional to the skew among + local notions of the party clock. + + + 6.3.6. Selective Clock Acceleration Mechanism + + The definition of the SNMPv2 security protocols requires that, + if either of the timestamp values for the originating or + receiving parties on a received, validated message exceeds the + corresponding local notion of the clock for that party, then + the local notion of the clock for that party is adjusted + forward to correspond to said timestamp value. This mechanism + is neither strictly necessary nor sufficient to the security + of the protocol; rather, it fosters the clock synchronization + on which valid message delivery depends - thereby enhancing + the effectiveness of the protocol in a management context. + + + if (msgIsValidated) { + if (timestampOfReceivedMsg > + party->localNotionOfClock) { + party->localNotionOfClock = + timestampOfReceivedMsg; + } + } + + + The effect of this mechanism is to synchronize local notions + of a party clock more closely in the case where a sender's + notion is more advanced than a receiver's. In the opposite + case, this mechanism has no effect on local notions of a party + clock and either the received message is validly delivered or + not according to other mechanisms of the protocol. + + Operation of this mechanism does not, in general, improve the + probability of validated delivery for messages generated by + party participants whose local notion of the party clock is + relatively less advanced. In this case, queries from a + management station may not be validly delivered and the + + + + + + Galvin & McCloghrie [Page 46] + + + + + + RFC 1446 Security Protocols for SNMPv2 April 1993 + + + management station needs to react appropriately (e.g., by use + of the strategy described in section 5.3). In contrast, the + delivery of SNMPv2 trap messages generated by an agent that + suffers from a less advanced notion of a party clock is more + problematic, for an agent may lack the capacity to recognize + and react to security failures that prevent delivery of its + messages. Thus, the inherently unreliable character of trap + messages is likely to be compounded by attempts to provide for + their validated delivery. + + + 6.3.7. Confidentiality Mechanism + + The protocols require the use of a symmetric encryption + algorithm when the data confidentiality service is required. + By virtue of this mechanism and assumption 3, the protocols + realize goal 4. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Galvin & McCloghrie [Page 47] + + + + + + RFC 1446 Security Protocols for SNMPv2 April 1993 + + + 7. Acknowledgements + + This document is based, almost entirely, on RFC 1352. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Galvin & McCloghrie [Page 48] + + + + + + RFC 1446 Security Protocols for SNMPv2 April 1993 + + + 8. References + + [1] Galvin, J., and McCloghrie, K., "Administrative Model for + version 2 of the Simple Network Management Protocol + (SNMPv2)", RFC 1445, Trusted Information Systems, Hughes + LAN Systems, April 1993. + + [2] Case, J., Fedor, M., Schoffstall, M., Davin, J., "Simple + Network Management Protocol", STD 15, RFC 1157, SNMP + Research, Performance Systems International, MIT + Laboratory for Computer Science, May 1990. + + [3] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, + MIT Laboratory for Computer Science, April 1992. + + [4] McCloghrie, K., and Galvin, J., "Party MIB for version 2 + of the Simple Network Management Protocol (SNMPv2)", RFC + 1447, Hughes LAN Systems, Trusted Information Systems, + April 1993. + + [5] Data Encryption Standard, National Institute of Standards + and Technology. Federal Information Processing Standard + (FIPS) Publication 46-1. Supersedes FIPS Publication 46, + (January, 1977; reaffirmed January, 1988). + + [6] Data Encryption Algorithm, American National Standards + Institute. ANSI X3.92-1981, (December, 1980). + + [7] DES Modes of Operation, National Institute of Standards + and Technology. Federal Information Processing Standard + (FIPS) Publication 81, (December, 1980). + + [8] Data Encryption Algorithm - Modes of Operation, American + National Standards Institute. ANSI X3.106-1983, (May + 1983). + + [9] Guidelines for Implementing and Using the NBS Data + Encryption Standard, National Institute of Standards and + Technology. Federal Information Processing Standard + (FIPS) Publication 74, (April, 1981). + + [10] Validating the Correctness of Hardware Implementations of + the NBS Data Encryption Standard, National Institute of + Standards and Technology. Special Publication 500-20. + + + + + + + Galvin & McCloghrie [Page 49] + + + + + + RFC 1446 Security Protocols for SNMPv2 April 1993 + + + [11] Maintenance Testing for the Data Encryption Standard, + National Institute of Standards and Technology. Special + Publication 500-61, (August, 1980). + + [12] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., + "Protocol Operations for version 2 of the Simple Network + Management Protocol (SNMPv2)", RFC 1448, SNMP Research, + Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., + Carnegie Mellon University, April 1993. + + [13] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., + "Transport Mappings for version 2 of the Simple Network + Management Protocol (SNMPv2)", RFC 1449, SNMP Research, + Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., + Carnegie Mellon University, April 1993. + + [14] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., + "Management Information Base for version 2 of the Simple + Network Management Protocol (SNMPv2)", RFC 1450, SNMP + Research, Inc., Hughes LAN Systems, Dover Beach + Consulting, Inc., Carnegie Mellon University, April 1993. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Galvin & McCloghrie [Page 50] + + + + + + RFC 1446 Security Protocols for SNMPv2 April 1993 + + + 9. Authors' Addresses + + James M. Galvin + Trusted Information Systems, Inc. + 3060 Washington Road, Route 97 + Glenwood, MD 21738 + + Phone: +1 301 854-6889 + EMail: galvin@tis.com + + + Keith McCloghrie + Hughes LAN Systems + 1225 Charleston Road + Mountain View, CA 94043 + US + + Phone: +1 415 966 7934 + Email: kzm@hls.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Galvin & McCloghrie [Page 51] + |