[saag] Review of draft-ietf-dhc-client-id

Alan DeKok <aland@deployingradius.com> Thu, 25 October 2012 10:37 UTC

Return-Path: <aland@deployingradius.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43DA221F896D; Thu, 25 Oct 2012 03:37:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7N7pvGykPg2z; Thu, 25 Oct 2012 03:37:11 -0700 (PDT)
Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6E04221F8910; Thu, 25 Oct 2012 03:37:11 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 2DC5022405AB; Thu, 25 Oct 2012 12:37:09 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at power.freeradius.org
Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nyBXXE+mm4f9; Thu, 25 Oct 2012 12:37:07 +0200 (CEST)
Received: from Thor.local (pas38-7-83-153-93-21.fbx.proxad.net [83.153.93.21]) by power.freeradius.org (Postfix) with ESMTPSA id E4F5B2240530; Thu, 25 Oct 2012 12:37:06 +0200 (CEST)
Message-ID: <50891651.8060902@deployingradius.com>
Date: Thu, 25 Oct 2012 12:37:05 +0200
From: Alan DeKok <aland@deployingradius.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: "saag@ietf.org" <saag@ietf.org>, draft-ietf-dhc-client-id@tools.ietf.org, IESG IESG <iesg@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [saag] Review of draft-ietf-dhc-client-id
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Oct 2012 10:37:12 -0000

  I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
 These comments were written primarily for the benefit of the security
area directors.  Document editors and WG chairs should treat these
comments just like any other last call comments.

  The document is small and simple.

  The document says:

...
   When a client receives a DHCP message containing a 'client
   identifier' option, the client MUST compare that client identifier to
   the one it is configured to send.  If the two client identifiers do
   not match, the client MUST silently discard the message.
...

  I find the "configured to send" text a little confusing.  In my view,
the process is more one of comparing a *received* 'client identifier'
with an *expected* 'client identifier'.  If they don't match, no
response is sent.  If they do match, the 'client identifier' is ACKed
verbatim.

  Saying that the server is "configured to send" a 'client identifier'
could be interpreted as it *always* sends a 'client identifier'.  The
intent (I believe) is instead to verify the one that is received.


  I do have a question about inter-operability.  As they note, RFC 2131
says that the DHCP server MUST NOT return the 'client identifier'
option.  This document changes that MUST NOT to a MUST, if the client
sends a 'client identifier'.

  Some implementations may have "inventive" interpretations of MUST NOT
requirements.  If this is the case, they may interpret a response with
'client identifier' as violating the protocol.  They may then discard
the message.

  So changing the protocol in this way could result in poor
implementations being denied access to the network.

  I would suggest updating the "Security Considerations" section to note
that in the absence of the authentication option (90), RFC 3118, anyone
can spoof the 'client identifier'.  It is a useful field, but not a
trusted one.

  Alan DeKok.