dhcpcd-discuss

Hi Mattieu

On 28/04/2018 09:30, Mattieu Baptiste wrote:
> So, with all the patches you committed recently to support the
> mandatory options, I finally managed to get a reply from the server.
> I use this minimal dhcpcd config:
>
> ipv6only
> duid
> authprotocol token
> authtoken 0 "" 0 fti/xxxxxxx
> userclass FSVDSL_livebox.Internet.softathome.livebox3
> vendclass 1038 sagem
> persistent
> noipv6rs
> allowinterfaces vlan832
> interface vlan832
>          ia_pd 1
>
> The point is I think my ISP is filtering on the DUID value. In order
> to have a reply from the server, I MUST use the exact same DUID that
> dibbler generates the first time I launched it some months ago.
> If I change one bit in it (link type, time or macaddress), the server
> doesn't reply anymore.
>
> I tried to change it with clientid, but in my comprehension it seems
> limited to DHCPv4: any value I set is ignored, and a DUID is
> generated.
> So, I edited /var/db/dhcpcd/duid to set the value that dibbler uses...
> and the server replies.
> Maybe it's a filtering policy to doesn't allow the client to use
> something else than the official internet boxes...

This is quite likely.
Added to the man page here:
https://roy.marples.name/git/dhcpcd.git/commit/?id=3532ad672ada845501796b30a8c5cca6e2f41979

> So now that the server replies, dhcpcd complains about not beeing able
> to authenticate the server:
> # dhcpcd -Bd
> dhcpcd-7.0.3 starting
> vlan832: executing `/usr/local/libexec/dhcpcd-run-hooks' PREINIT
> vlan832: executing `/usr/local/libexec/dhcpcd-run-hooks' CARRIER
> DUID 00:01:00:06:20:f6:4d:7a:00:0d:b9:33:8e:8c
> vlan832: IAID ff:00:03:40
> vlan832: IAID 00:00:00:01
> vlan832: reading lease `/var/db/dhcpcd/vlan832.lease6'
> vlan832: soliciting a DHCPv6 lease
> vlan832: delaying SOLICIT6 (xid 0xbea62c), next in 0.4 seconds
> vlan832: broadcasting SOLICIT6 (xid 0xbea62c), next in 0.9 seconds
> vlan832: authentication failed from fe80::ba0:bab: Operation not permitted
> vlan832: broadcasting SOLICIT6 (xid 0xbea62c), next in 1.9 seconds
> vlan832: authentication failed from fe80::ba0:bab: Operation not permitted
> vlan832: broadcasting SOLICIT6 (xid 0xbea62c), next in 3.9 seconds
> vlan832: authentication failed from fe80::ba0:bab: Operation not permitted
> ^Creceived SIGINT, stopping
> vlan832: removing interface
> vlan832: executing `/usr/local/libexec/dhcpcd-run-hooks' STOPPED
> dhcpcd exited
>
> I send:
> Authentication
>      Option: Authentication (11)
>      Length: 22
>      Value: 000000de8eac8dc8f3228f6674692fXXXXXXXXXXXXXX
>      Protocol: 0
>      Algorithm: 0
>      RDM: 0
>      Replay Detection: de8eac8dc8f3228f
>      Authentication Information: 6674692fXXXXXXXXXXXXXX
>
> The server replies with:
> Authentication
>      Option: Authentication (11)
>      Length: 27
>      Value: 0000000000000000000000646863706c697665626f786672...
>      Protocol: 0
>      Algorithm: 0
>      RDM: 0
>      Replay Detection: 0000000000000000
>      Authentication Information: 646863706c697665626f786672323530
> (The value is the string: dhcpliveboxfr)
>
> Maybe the replay detection in the advertise isn't correct?
> Or, shouldn't I set the server authentication parameters in dhcpcd's config?

Oh the replay dhcpcd is sending *is* correct.
What is NOT correct is the server's reply.
Well, if you really really really want to pick nits the is as the errata 
update is only for RFC3118 and not RFC3115 even though the 
authentication description is 100% identical.

Attached is a patch for this, along with the prior patch so we're just 
maintiaing one patch until this is resolved!

BTW, now that you have obtained a reply from dhcpcd, do you get a reply 
if the authentication option is omitted from the requested options?

Roy

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. */
diff --git a/src/dhcp6.c b/src/dhcp6.c
index 6e470a98..a6e2bbd8 100644
--- a/src/dhcp6.c
+++ b/src/dhcp6.c
@@ -3705,6 +3705,8 @@ dhcp6_start1(void *arg)
 		if (ifo->fqdn != FQDN_DISABLE ||
 		    ifo->options & DHCPCD_HOSTNAME)
 			add_option_mask(ifo->requestmask6, D6_OPTION_FQDN);
+		if (ifo->auth.options & DHCPCD_AUTH_SENDREQUIRE)
+			add_option_mask(ifo->requestmask6, D6_OPTION_AUTH);
 	}
 
 #ifndef SMALL