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

From: Alan DeKok <[email-masked]>
Date: Thu, 25 Oct 2012 12:37:05 +0200

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.