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:
Its destination supports the Symmetric Privacy Protocol and the Digest Authentication Protocol.
Its destination supports the Symmetric Privacy Protocol and the Digest Authentication Protocol.
Second, modifying the current secret of an existing party:
If the responsible management station does not receive a response to its request, there are two possible causes.
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 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.