Re: [Gen-art] Gen-ART LC Review of draft-ietf-dhc-forcerenew-nonce-03

Ted Lemon <> Sat, 11 February 2012 16:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7537E21F84B9; Sat, 11 Feb 2012 08:24:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.51
X-Spam-Status: No, score=-106.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wrm4CJa6PWHr; Sat, 11 Feb 2012 08:24:38 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 84A3F21F8497; Sat, 11 Feb 2012 08:24:37 -0800 (PST)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID; Sat, 11 Feb 2012 08:24:37 PST
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by (Postfix) with ESMTP id 31ECA1B82C5; Sat, 11 Feb 2012 08:24:36 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by (Postfix) with ESMTPS id 20188190052; Sat, 11 Feb 2012 08:24:36 -0800 (PST) (envelope-from
Received: from MBX-01.WIN.NOMINUM.COM ([]) by CAS-01.WIN.NOMINUM.COM ([]) with mapi id 14.01.0339.001; Sat, 11 Feb 2012 08:24:30 -0800
From: Ted Lemon <>
To: Maglione Roberta <>
Thread-Topic: Gen-ART LC Review of draft-ietf-dhc-forcerenew-nonce-03
Thread-Index: AQHM5SWUy8EqSdK3C0aOhQFr8l21aJY2slwAgAG8tQA=
Date: Sat, 11 Feb 2012 16:24:29 +0000
Message-ID: <>
References: <> <282BBE8A501E1F4DA9C775F964BB21FE3EC1467FB2@GRFMBX704BA020.griffon.local>
In-Reply-To: <282BBE8A501E1F4DA9C775F964BB21FE3EC1467FB2@GRFMBX704BA020.griffon.local>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Ben Campbell <>, The IETF <>, " Review Team" <>, "" <>, Ullio Mario <>, "Henderickx, Wim (Wim)" <>
Subject: Re: [Gen-art] Gen-ART LC Review of draft-ietf-dhc-forcerenew-nonce-03
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 11 Feb 2012 16:24:38 -0000

> [RM] The intention is to use this method only for environments with native security mechanisms, such as the Broadband Access network. You are right it is not clearly said in the document I can add the following sentence at the end of the introduction in order to clarify this point:
> "This   mechanism is intended to be use in networks that already have native security mechanisms that provide sufficient protection against
> spoofing of DHCP traffic."

It's probably worth revisiting the purpose of this mechanism.   The problem that we are trying to solve is that people are reluctant to implement DHCPFORCERENEW because it's possible that an off-link attacker could more accurately guess the timing of DHCP renewal messages by first sending a DHCPFORCERENEW.   The mechanism in RFC3315 (DHCPv6), which this document mirrors for DHCPv4, uses a nonce to prevent an off-link attacker from successfully triggering a renewal on a client by sending DHCPFORCERENEW; since the attacker is off-link, it doesn't have the nonce, and can't force a renewal.

An on-link attacker can always simply watch the DHCP renewal message go out and respond to it, so this mechanism is useless for preventing on-link attacks, and hence the security of the nonce in the case of on-link attacks isn't relevant.  So the above text isn't needed.   It's possible that the document doesn't clearly document the use case for this functionality; if so, you are free to take the above paragraph, Roberta, and modify it to suit your purposes.   But I am against adding the text you proposed, because it excludes the bulk of use cases for the DHCPFORCERENEW nonce mechanism.

> [RM] This is because this mechanism relays on the authentication protocol defined in section 21.5 of RFC 3315 for DHCPv6 Reconfigure and there HMAC-MD5 is used.

Essentially HMAC-MD5 is being used here to package a secret into a chunk of predictable size, and the fact that there are hacks for the mechanism isn't terribly important because the only attacker we are attempting to foil is one that doesn't have access to the cleartext or the ciphertext.