Connected: An Internet Encyclopedia
6.3.4. Restricted Administration Mechanism

Up: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 1446
Up: 6. Security Considerations
Up: 6.3. Protocol Correctness
Prev: 6.3.3. Data Origin Authentication Mechanism
Next: 6.3.5. Message Timeliness Mechanism

6.3.4. Restricted Administration Mechanism

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.

        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;
            }
        }


Next: 6.3.5. Message Timeliness Mechanism

Connected: An Internet Encyclopedia
6.3.4. Restricted Administration Mechanism