RFC Errata
Found 1 record.
Status: Verified (1)
RFC 3118, "Authentication for DHCP Messages", June 2001
Source of RFC: dhc (int)
Errata ID: 3474
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Chris Lonvick
Date Reported: 2013-02-02
Verifier Name: Ralph Droms
Date Verified: 2013-03-09
Section 2 says:
If the RDM field contains 0x00, the replay detection field MUST be set to the value of a monotonically increasing counter. Using a counter value such as the current time of day (e.g., an NTP-format timestamp [4]) can reduce the danger of replay attacks. This method MUST be supported by all protocols.
It should say:
If the RDM field contains 0x00, the replay detection field MUST be set to the value of a strictly increasing counter. Using a counter value such as the time since the epoch (e.g., an NTP-format timestamp [4]) can reduce the danger of replay attacks. This method MUST be supported by all protocols.
Notes:
The term "monotonically increasing" does not actually mean what the authors and editors hope it means. :-) An example of a monotonically increasing sequence is:
1, 2, 2, 2, 2, 2, 2...
Strictly following that definition in the current section 2 would allow replays of captured packets. Changing the term to "strictly increasing" requires that subsequent values are greater than previous values. This would mean that a captured packet replayed with the same Authentication Information value would not meet the criteria described in my proposed corrected text, and should consequently be detected as a replay attack by a recipient.
The term monotonically increasing is also used at the end of Section 6 and should also be replaced with strictly increasing.
Also, the use of the term "time of day" could be problematic. If the first packet were sent just before midnight, and the second sent just after midnight, then the value of the second would be much lower than the value of the first. To align with the NTP example, I'm suggesting a change in text to be something that is actually increasing.