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.

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.

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.

• The request may not have been delivered to the destination.

• 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 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.