From: Roy Marples <roy@marples.name>
Date: Sun, 29 Apr 2018 20:28:15 +0000 (+0100)
Subject: auth: allow zero value replay detection data
X-Git-Tag: v7.0.4~6
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=5b0fec0584b2eda14f9a3ab8c7c18e91c1e7be39;p=thirdparty%2Fdhcpcd.git

auth: allow zero value replay detection data

It seems one ISP doesn't use Replay Data and always sets it to zero.
See the comment in the commit as to why this is technically legal,
even if it goes against the intent of the RFC.
---

diff --git a/src/auth.c b/src/auth.c
index be7dd7ad..93e8b774 100644
--- a/src/auth.c
+++ b/src/auth.c
@@ -151,7 +151,24 @@ dhcp_auth_validate(struct authstate *state, const struct auth *auth,
 
 	memcpy(&replay, d, sizeof(replay));
 	replay = ntohll(replay);
-	if (state->token) {
+	/*
+	 * Test for a replay attack.
+	 *
+	 * NOTE: Some servers always send a replay data value of zero.
+	 * This is strictly compliant with RFC 3315 and 3318 which say:
+	 * "If the RDM field contains 0x00, the replay detection field MUST be
+	 *    set to the value of a monotonically increasing counter."
+	 * An example of a monotonically increasing sequence is:
+	 * 1, 2, 2, 2, 2, 2, 2
+	 * Errata 3474 updates RFC 3318 to say:
+	 * "If the RDM field contains 0x00, the replay detection field MUST be
+	 *    set to the value of a strictly increasing counter."
+	 *
+	 * Taking the above into account, dhcpcd will only test for
+	 * strictly speaking replay attacks if it receives any non zero
+	 * replay data to validate against.
+	 */
+	if (state->token && state->replay != 0) {
 		if (state->replay == (replay ^ 0x8000000000000000ULL)) {
 			/* We don't know if the singular point is increasing
 			 * or decreasing. */