📄 rfc1352.txt
字号:
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 SNMP 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 SNMP 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. 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 6.3. In addition to correcting skewed notions of authentication clocks, every SNMP entity must react correctly as an authentication clock approaches its maximal value. If the authentication clock for a particular SNMP party ever reaches the maximal time value, the clock must halt at that value. (The value of interest may be the maximum less lifetime. When authenticating a message, its authentication timestamp is added to lifetime and compared to the authentication clock. A SNMP protocol entity must guarantee that the sum is never greater than the maximal time value.) In this state, the only authenticated request a management station should generate for this party is one that alters the value of at least its authentication clock and private authentication key. In order to reset these values, the responsible management station may set the authentication timestamp in the message to the maximal time value. In this case, theGalvin, McCloghrie, & Davin [Page 23] RFC 1352 SNMP Security Protocols July 1992 nonce value may be used to distinguish multiple messages. The value of the authentication clock for a particular SNMP party must never be altered such that its new value is less than its old value, unless its last-timestamp and private authentication key are also altered at the same time.6.3 Clock Synchronization Unless the secrets are changed at the same time, the correct way to synchronize clocks is to advance the slower clock to be equal to the faster clock. Suppose that party agentParty is realized by the SNMP entity in a managed agent; suppose that party mgrParty is realized by the SNMP 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. 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 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 1, condition 4, or both of those conditions are manifest. 1. The responsible management station saves its existing notions of the authentication clocks for the two parties agentParty and mgrParty. 2. The responsible management station retrieves the authentication clock values for both agentParty and mgrParty from the agent. This retrieval must be anGalvin, McCloghrie, & Davin [Page 24] RFC 1352 SNMP Security Protocols July 1992 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 management station's notion of the authentication clock for agentParty exceeds the notion just retrieved from the agent by more than the amount of the communications delay between the two protocol entities, then condition 1 is manifest. The recommended estimate of communication delay in this context is one half of the lifetime value recorded for agentParty. 4. If the notion of the authentication clock for mgrParty just retrieved from the agent 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. 5. If condition 1 is manifest, then the responsible management station sends an authenticated management operation to the agent that advances the agent's notion of the authentication clock for agentParty to be equal to the management station's notion. If this management operation fails, then the management station restores its previously saved notions of the clock values, and the clock adjustment procedure is aborted without further processing. 6. The responsible management station retrieves the authentication clock values for both agentParty and mgrParty from the agent. This retrieval must be an authenticated request, in order that the management station may verify that the clock values are properly synchronized. If this authenticated query fails, then the management station restores its previously saved notions of the clock values, and the clock adjustment procedure is aborted without further processing. Otherwise, clock synchronization has been successfully realized. It is important to note step 4 above must be completed before attempting step 5. Otherwise, the agent may evaluate the request in step 5 as unauthentic. Similarly, step 5 above must be completed before attempting step 6. Otherwise, the management station may evaluate the query response in step 6 as unauthentic.Galvin, McCloghrie, & Davin [Page 25] RFC 1352 SNMP Security Protocols July 1992 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 management operations that are authenticated using a previous value of the relevant party clock. This possibility may be avoided if a management station suppresses generation of management traffic between relevant parties while this clock adjustment procedure is in progress.6.4 Secret Distribution This section describes one strategy by which a SNMP protocol entity that supports both the Digest Authentication Protocol and the Symmetric Privacy Protocol can change the secrets for a particular SNMP party. The frequency with which the secrets of a SNMP 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 7). Note that, owing to both administrative and automatic advances of the authentication clock described in this memo, the authentication clock for a SNMP party may well approach its maximal value sooner than might otherwise be expected. The following sequence of steps specifies how a responsible management station alters a secret value (i.e., the private authentication key or the private privacy key) for a particular SNMP party. 1. The responsible management station generates a new secret value. 2. The responsible management station encapsulates a SNMP Set request in a SNMP private management communication with at least the following properties. o Its source supports the Digest Authentication Protocol and the Symmetric Privacy Protocol. o Its destination supports the Symmetric Privacy Protocol and the Digest Authentication Protocol. 3. The SNMP private management communication is transmitted to its destination. 4. Upon receiving the request, the recipient processes theGalvin, McCloghrie, & Davin [Page 26] RFC 1352 SNMP Security Protocols July 1992 message according to [1] and [2]. 5. The recipient encapsulates a SNMP Set response in a SNMP private management communication with at least the following properties. o Its source supports the Digest Authentication Protocol and the Symmetric Privacy Protocol. o Its destination supports the Symmetric Privacy Protocol and the Digest Authentication Protocol. 6. The SNMP 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. 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 using the public values may make use of this strategy directly.) One other scenario worthy of mention is using a SNMP party to changeGalvin, McCloghrie, & Davin [Page 27] RFC 1352 SNMP Security Protocols July 1992 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.6.5 Crash Recovery This section describes the requirements for SNMP protocol entities in connection with recovery from system crashes or other service interruptions. For each SNMP party in the local database for a particular SNMP protocol entity, its identity, authentication clock, private authentication key, and private privacy key must e⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -