dhcpcd-discuss

On 29/04/2018 11:00, Mattieu Baptiste wrote:
> Alas with the patch, I have the same "authentication failed" behavior:
> # 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 0x2bfb39), next in 0.0 seconds
> vlan832: broadcasting SOLICIT6 (xid 0x2bfb39), next in 1.0 seconds
> vlan832: authentication failed from fe80::ba0:bab: Operation not permitted
> vlan832: broadcasting SOLICIT6 (xid 0x2bfb39), next in 1.9 seconds
> vlan832: authentication failed from fe80::ba0:bab: Operation not permitted
> vlan832: broadcasting SOLICIT6 (xid 0x2bfb39), next in 3.6 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
>
> Here is the full dhcpv6 advert the server send me:
> DHCPv6
>      Message type: Advertise (2)
>      Transaction ID: 0x191db8
>      Identity Association for Prefix Delegation
>          Option: Identity Association for Prefix Delegation (25)
>          Length: 41
>          Value: 000000010000b98400032a00001a00190003f4800003f480...
>          IAID: 00000001
>          T1: 47492
>          T2: 207360
>          IA Prefix
>              Option: IA Prefix (26)
>              Length: 25
>              Value: 0003f4800003f480382a01cb0007c87f0000000000000000...
>              Preferred lifetime: 259200
>              Valid lifetime: 259200
>              Prefix length: 56
>              Prefix address: 2a01:cb00:7c8:7f00::
>      Server Identifier
>          Option: Server Identifier (2)
>          Length: 20
>          Value: 0002000005584445534841594553535544524f54
>          DUID: 0002000005584445534841594553535544524f54
>          DUID Type: assigned by vendor based on Enterprise number (2)
>          Enterprise ID: Orange (formerly 'France Telecom') (1368)
>          Identifier: 4445534841594553535544524f54
>      Client Identifier
>          Option: Client Identifier (1)
>          Length: 14
>          Value: 0001000620f64d7a000db9338e8c
>          DUID: 0001000620f64d7a000db9338e8c
>          DUID Type: link-layer address plus time (1)
>          Hardware type: IEEE 802 (6)
>          DUID Time: Jul 10, 2017 16:36:42.000000000 CEST
>          Link-layer address: 00:0d:b9:33:8e:8c
>      Authentication
>          Option: Authentication (11)
>          Length: 27
>          Value: 0000000000000000000000646863706c697665626f786672...
>          Protocol: 0
>          Algorithm: 0
>          RDM: 0
>          Replay Detection: 0000000000000000
>          Authentication Information: 646863706c697665626f786672323530
>      Preference
>          Option: Preference (7)
>          Length: 1
>          Value: ff
>          Pref-value: 255

WOW!
You're using token authentication, but the token you're sending does not 
match the token being sent back. This is not what I expected.

Can I see your working dibbler configuration please?
Looking at the dibbler documentation (I can't read the source, it hurts 
my eyes and I don't understand c++ too well) they don't even have an 
option for sending token based authentication which is what it's 
actually sending ....

But it might we we need two tokens, 1 the server expects and 2 the 
client expects. I've always taken the assumption that both are the same.
Test this new patch for auth.c
It disables the returned token check. If this works then I guess we need 
an option to specify the receive token as well as the send token.

Roy

diff --git a/src/auth.c b/src/auth.c
index be7dd7ad..2265e241 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. */
@@ -300,6 +317,8 @@ gottoken:
 
 	/* Special case as no hashing needs to be done. */
 	if (protocol == AUTH_PROTO_TOKEN) {
+		/* Test different token. */
+		goto finish;
 		if (dlen != t->key_len || memcmp(d, t->key, dlen)) {
 			errno = EPERM;
 			return NULL;
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