6.2. Conformance

A SNMPv2 entity implementation that claims conformance to this memo must satisfy the following requirements:

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:
   1. 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.

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

      This prohibition includes prevention of read-access by the entity's human operators.

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

   4. 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).

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

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

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