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

From: Kyle Rose <[email-masked]>
Date: Wed, 17 Jan 2018 16:39:38 -0500

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.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 19 Jan 2018 14:53:32 +0000

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:[email-masked]]
Sent: Wednesday, January 17, 2018 4:40 PM
To: The IESG <[email-masked]>; [email-masked]; [email-masked]
Subject: Secdir last call review of draft-ietf-dhc-rfc3315bis-10

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.

---

From: Kyle Rose <[email-masked]>
Date: Mon, 22 Jan 2018 12:25:17 -0500

On Fri, Jan 19, 2018 at 9:53 AM, Bernie Volz (volz) <[email-masked]> wrote:

> 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).
>

My pleasure. I hope the feedback was helpful.

> 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).
>
>
Understood. I personally feel that this is not a problem, for three reasons:

(1) It's documentation of an existing practice, not a new use of MD5.
(2) AFAIK HMAC-MD5 has not actually been broken.
(3) The protected resource's attack surface has much weaker points in the
real world than attacking the crypto.

That said, I raised it because normatively specifying MD5 in a standard may
not be appropriate for a standard published in 2018. However, going back
through the text right now, it appears to already be worded less as a
normative specification than as an informational description of "this is
how you interoperate with existing deployments", which I think is entirely
appropriate for a proposed standard with legacy components.

It may still be worthwhile to separately pursue a replacement for RKAP that
incorporates algorithmic agility.

Kyle