From philipp@redfish-solutions.com Fri Aug 18 23:56:29 2017 Date: Fri, 18 Aug 2017 17:56:25 -0600 From: "Philip Prindeville" Delivered-To: dhcp-confidential@bugs.isc.org content-type: text/plain; charset="utf-8" X-RT-Incoming-Encryption: Not encrypted X-Scanned-BY: MIMEDefang 2.79 on 192.168.1.3 Subject: Implementing RFC-6355 Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx.pao1.isc.org", Issuer "COMODO RSA Organization Validation Secure Server CA" (not verified)) by bugs.isc.org (Postfix) with ESMTPS id 23AB2D78AED for ; Fri, 18 Aug 2017 23:56:29 +0000 (UTC) Received: from mail.redfish-solutions.com (mail.redfish-solutions.com [66.232.79.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id E55E834A1B8 for ; Fri, 18 Aug 2017 23:56:26 +0000 (UTC) Received: from macmini.redfish-solutions.com (macmini.redfish-solutions.com [192.168.1.38]) (authenticated bits=0) by mail.redfish-solutions.com (8.15.2/8.15.2) with ESMTPSA id v7INuPXw009956 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 18 Aug 2017 17:56:25 -0600 MIME-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mx.pao1.isc.org To: dhcp-bugs@isc.org X-Mailer: Apple Mail (2.3273) Content-Transfer-Encoding: quoted-printable Return-Path: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=ham autolearn_force=no version=3.4.0 Message-ID: X-Original-To: dhcp-confidential@bugs.isc.org X-RT-Original-Encoding: utf-8 X-RT-Interface: Email Content-Length: 2703 Hi. I was going through the sources of 4.3.5, in particular, how the DUID_LL is generated, and it seems wrong. Quoting the RFC, we have: 4. DUID-UUID Format The DUID-UUID is carried within Client Identifier or Server Identifier options. It has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DUID-Type (4) | UUID (128 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Figure 1: DUID-UUID Format DUID-Type - DUID-UUID (4) - (16 bits) UUID - An [RFC4122] UUID (128 bits) but the code fragment: } else { putUShort(duid->buffer->data, DUID_LL); putUShort(duid->buffer->data + 2, ip->hw_address.hbuf[0]); memcpy(duid->buffer->data + 4, ip->hw_address.hbuf + 1, ip->hw_address.hlen - 1); } in client/dhclient.c circa line 3485 does something entirely different. The first putUShort() is correct, but the code should look like this: // typedef char uuid_t[16]; uuid_t *uuid; char digest[ISC_MD5_DIGESTLENGTH]; isc_md5_t ctx; isc_md5_init(&ctx); isc_md5_update(&ctx, NameSpace_OID, sizeof(NameSpace_OID)); isc_md5_update(&ctx, &ip->hw_address.buf[1], ip->hw_address.hlen - 1); // alternatively, you could also run the hash over the type // isc_md5_update(&ctx, ip->hw_address.buf, ip->hw_address.hlen); isc_md5_final(&ctx, digest); putUShort(duid->buffer->data, DUID_LL); // build UUID in-place uuid = (uuid_t *) &duid->buffer->data + 2; memcpy(uuid, digest, sizeof(uuid_t)); uuid[6] &= ~(0xf << 4); uuid[6] |= (3 << 4); // version 3, MD5 uuid[8] &= ~(0x7 << 5); uuid[8] |= (4 << 5); // DCE variant duid->len = 2 + sizeof(uuid_t); And NameSpace_OID (which comes from RFC-4122, section C) would look like: const uuid_t NameSpace_OID = { 0x6b, 0xa7, 0xb8, 0x12, 0x9d, 0xad, 0x11, 0xd1, 0x80, 0xb4, 0x00, 0xc0, 0x4f, 0xd4, 0x30, 0xc8 }; Unless I’m missing something obvious. But Section 4 of RFC-6355 seems pretty unequivocal about the DUID-UUID being 2 bytes of type (0x0004) followed by 16 bytes of UUID. That is not what is currently going on in the current code. Thanks, -Philip