Re: [secdir] Secdir last call review of draft-ietf-dhc-rfc3315bis-10

["Bernie Volz (volz)" <[e-mail]>]

Kyle:

On behalf of the authors of draft-ietf-dhc-rfc3315bis, thanks much for the very thorough review (this email and your other email with the nits – most of those nits look appropriate to apply).

Regarding the HMAC-MD5 issue: That was what RFC 3315 specified. Also, the AUTH Option (except for use by RKAP) is being deprecated. For RKAP, there is also a flaw as there is no means for the client to indicate the algorithms it supports and the server generates this key – so what it uses must be supported by the client for it to work. Therefore, simply changing algorithms is not very really possible (likely it would require a NEW option to have the client communicate which algorithm(s) it supports).


-          Bernie

From: Kyle Rose [mailto:[e-mail]]
Sent: Wednesday, January 17, 2018 4:40 PM
To: The IESG <[e-mail]>; [e-mail]; [e-mail]
Subject: Secdir last call review of draft-ietf-dhc-rfc3315bis-10

Let me try sending this to the right .all address.
Reviewer: Kyle Rose
Review result: Ready with issues

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.

13.1: "By default, DHCP server implementations SHOULD NOT generate predictable addresses." The justification for this is not addressed in the security considerations section, while the privacy considerations section might be punting this to RFC 7824, though the only mention I can find in a quick search regards iterative allocation in section 4.3.

20.4.1: RKAP uses HMAC-MD5 for symmetric authentication. As an informational matter for an existing protocol, this is certainly justified, but I don't know how the IETF handles obsolete crypto in standards revisions.

20.4.3: "...the client computes an HMAC-MD5 over the DHCP Reconfigure message [ADD: with zeroes substituted for the HMAC-MD5 field], using the Reconfigure Key received from the server"

22. DHCP's security threat model is not clearly stated. For instance, RKAP provides protection against man-on-the-side reconfiguration attacks, but DHCP has no ability by itself to protect against a race between legitimate and rogue DHCP servers: such protection relies on management of multicast groups at layer 2. This is implied by the paragraph on snooping DHCP multicast traffic, but nowhere is it specified normatively that restrictive group management is necessary to eliminate this part of the attack surface. Similarly, it's not clear to me whether a rogue or misconfigured server temporarily in the All_DHCP_Servers or All_DHCP_Relay_Agents_and_Servers multicast group can then hide a client from the official DHCP servers forever by sending it the unicast option, thus maintaining exclusive access to certain messages, notabley Request and Renew. The threat model should be stated clearly in this document, even if the recommended countermeasures are in some other RFC (such as RFC 7610) because they rely on information not in this document.

23. Does it make sense to clarify the threat model for privacy? For instance, this protocol doesn't try to defend clients against tracking within a LAN that can observe the DHCP traffic. I can guess what the threat model is, but ISTM that it should be specified explicitly.