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

From: Ben Campbell <[email-masked]>
Date: Mon, 6 Feb 2012 17:17:22 -0600

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments you may receive.

Document: draft-ietf-dhc-forcerenew-nonce-03
Reviewer: Ben Campbell
Review Date: 2012-02-06
IETF LC End Date: 2012-02-06

Summary:This draft is not quite ready for publication as a proposed standard. There are some potentially significant issues that should be addressed first.

[Note: Hopefully this draft has had or will have a SecDir review, since it seems ripe for significant security implications.]

*** Major issues:

-- I admit to not being a DHCP expert, but If I understand this draft correctly, it proposes to send what is effectively a secret-key in a DHCPACK request, then use that key to authenticate a force renew message. It seems like any eavesdropper could sniff that key, and use it to spoof force renew requests. The introduction mentions that there may be some environments where the use of RFC3118 authentication could be relaxed, and offers an example of such an environment. But nowhere does this draft appear to be limited in scope to such environments. 

I think some additional text in (perhaps in the security considerations) is needed to explain either why the vulnerability to eavesdroppers is either okay in general, or limits the mechanism's use to environment where it is okay. It also seems like that, in the best case, this mechanism proves only that a Forcerenew request comes from the same DHCP server as in the original transaction, but otherwise does not prove anything about the identity of that server. If so, it would be worth mentioning it.

-- The mechanism appears to be limited to HMAC-MD5, and there does not appear to be any way of selecting other algorithms. Is HMAC-MD5 really sufficient as the only choice? Is there some expectation that stronger mechanisms or algorithm extensibility would be too expensive? (Perhaps the extensibility method would be to specify another mechanism that's identical except for a different HMAC algorithm. But if that's the intent it should be mentioned.)

*** Minor issues:

-- Section 1 " 
In such environments the mandatory coupling between FORCERENEW and DHCP Authentication [RFC3118] can be relaxed."

It's not clear to me what connection that assertion has with this draft. Is there an intent that the proposed mechanisms be used only in such environments? I don't find any language scoping this proposal to any particular environment.

-- section 3:

Does this draft update either 3203 or 3118? If so, please state that explicitly in the abstract, introduction, and draft headers. (I think it must at least update 3203, since that draft requires the use of 3118, and this draft relaxes that.)

-- section 3.1, last paragraph: "...only if the client and server are not using any other authentication..."

That seems to conflict with the statement in section 3 that this mechanism is only used if RFC3118 is not used. That is, it's not a choice between this mechanism or any other mechanism, it's a choice between this mechanism or 3118.

-- section 3.1.3, 2nd paragraph: "The server SHOULD NOT include this option unless the client has indicated its capability in a DHCP Discovery message."

Why not; what harm would it do? And on the other hand, if you want to discourage it, why not go all the way to "MUST NOT"?

-- section 3.1.3, 5th paragraph: "...  computes an HMAC-MD5 of the Forcerenew message using the Forcerenew nonce …"

Using it how? Is it the secret key for the HMAC calculation? (If so, why aren't we calling it a "key" in the first place?)

-- section 3.1.4, 1st paragraph: "DHCP servers that support Forcerenew nonce Protocol authentication MUST include the DHCP Forcerenew Nonce protocol authentication option…"

Only if the client advertised it, right? Otherwise, this seems to conflict with the previous SHOULD NOT.

-- section 3.1.4, 4th paragraph: "…  
the client computes an HMAC-MD5 over the DHCP Forcerenew message, using the Forcerenew Nonce …"

Using it how?

-- section 6:

You mention this mechanism is vulnerable to MiTM attacks. Why is this okay? Are there some environments where it is good enough and others where it is not? (Also, do they really need to be MitM attackers? Seems like any eavesdropper could learn the nonce.)

*** Nits/editorial comments:

-- Abstract, second sentence:

I have trouble parsing this sentence. Are the propositions correct?

-- Section 3.1.1,4th paragraph: "… configured to require …"

Do you mean configured to "require", or configured to "use"? I would normally take "requires" to mean that the server would not work with clients that don't advertise support for the mechanism.

-- section 3.1.1, message flow diagram:

It would be helpful if you could avoid widowing the top of the diagram. One has to keep flipping back to see the labels.

-- section 3.1.3, 5th paragraph: 

Please expand "RDM"

-- section 3.1.4, first paragraph: "The client MUST…"

A client that supports this mechanism MUST…

-- section 3.1.4, 2nd and third paragraph, 1st sentence of each:

I'm confused by this sentence of each paragraph. Are they intended as conditionals for the rest of the respective paragraph?

---

From: Ben Campbell <[email-masked]>
Date: Mon, 6 Feb 2012 17:27:39 -0600

Additionally, the I got a failed delivery notice (User Unknow) for David Miles's address.

---

From: Maglione Roberta <[email-masked]>
Date: Fri, 10 Feb 2012 14:52:48 +0100

Hello Ben,
   Thanks for reviewing this document.
Please see answers inline [RM]

Best regards,
Roberta

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]]
Sent: martedì 7 febbraio 2012 0.17
To: [email-masked]
Cc: [email-masked] Review Team; The IETF
Subject: Gen-ART LC Review of draft-ietf-dhc-forcerenew-nonce-03

*** Major issues:

[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."

[RM] That's correct this mechanism only proves only that a Forcerenew request comes from the same DHCP server: let me say this is a trade off between the total security provided by RFC 3118 and no security at all. In addition this method relays on the same mechanism already used for DHCPv6 Reconfigure message

-- The mechanism appears to be limited to HMAC-MD5, and there does not appear to be any way of selecting other algorithms. Is HMAC-MD5 really sufficient as the only choice? Is there some expectation that stronger mechanisms or algorithm extensibility would be too expensive? (Perhaps the extensibility method would be to specify another mechanism that's identical except for a different HMAC algorithm. But if that's the intent it should be mentioned.)
[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.

*** Minor issues:

-- Section 1 "

[RM] The intention is to use this method only in environments with native security mechanisms, I'll try to clarify this point

-- section 3:

Does this draft update either 3203 or 3118? If so, please state that explicitly in the abstract, introduction, and draft headers. (I think it must at least update 3203, since that draft requires the use of 3118, and this draft relaxes that.)
[RM] Yes that's correct, it updates 3203, I'll add it in the document.

That seems to conflict with the statement in section 3 that this mechanism is only used if RFC3118 is not used. That is, it's not a choice between this mechanism or any other mechanism, it's a choice between this mechanism or 3118.
[RM] I'll clarify the sentence

[RM] For backward compatibility: if the client did not indicate its capability for this feature it means it is a legacy client and it does not support it, so the server should not send the nonce to this client

-- section 3.1.3, 5th paragraph: "...  computes an HMAC-MD5 of the Forcerenew message using the Forcerenew nonce ."

Using it how? Is it the secret key for the HMAC calculation? (If so, why aren't we calling it a "key" in the first place?)
[RM] based on the procedure specified in section 21.5 of RFC 3315

-- section 3.1.4, 1st paragraph: "DHCP servers that support Forcerenew nonce Protocol authentication MUST include the DHCP Forcerenew Nonce protocol authentication option."

[RM] ok

-- section 3.1.4, 4th paragraph: ".
the client computes an HMAC-MD5 over the DHCP Forcerenew message, using the Forcerenew Nonce ."

Using it how?
[RM] based on the procedure specified in section 21.5 of RFC 3315

-- section 6:

*** Nits/editorial comments:
[RM] I'll address the following comments too.

-- Section 3.1.1,4th paragraph: ". configured to require ."

Please expand "RDM"

-- section 3.1.4, first paragraph: "The client MUST."

A client that supports this mechanism MUST.

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

---

From: Ted Lemon <[email-masked]>
Date: Sat, 11 Feb 2012 16:24:29 +0000

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

---

From: Ben Campbell <[email-masked]>
Date: Mon, 13 Feb 2012 14:37:26 -0600

Hi, thanks for the response. See additional comments inline. (I removed sections for which no further comment seems necessary)

On Feb 10, 2012, at 7:52 AM, Maglione Roberta wrote:

[...]

> spoofing of DHCP traffic."

That helps, although I would suggest an additional sentence mentioning the specific risk in using it in environments without sufficient protection. I note, however, that Ted objected to this in a separate email--I will reply there as well.

> [RM] That's correct this mechanism only proves only that a Forcerenew request comes from the same DHCP server: let me say this is a trade off between the total security provided by RFC 3118 and no…

Understood, and your suggested text from the previous comment mitigates this a bit. It would help to include text describing exactly what security properties you expect from the mechanism. (e.g. Proving (with limitations) that Forcerenew requests come from the same server as the original transaction response, etc.)

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

RFC 3315 was published in 2003. I'm not sure the general impression of HMACMD5 is the same now as it was in 2003. For example, http://www.ietf.org/mail-archive/web/cfrg/current/msg01197.html . I'm willing to accept that HMACMD5 is perfectly okay for this application, but it would be good to document more motivation than the fact it was used in 3315. If 3315 was being written today, would they use it? Is matching 3315 an important goal? I'm more interested in whether HMACMD5 is adequate for this particular use case based on today's knowledge about possible vulnerabilities or operational issues.

[I mentioned in my original review that I think this draft should get a SecDir review. They could certainly access whether hmacmd5 is an issue better than I can.]

> *** Minor issues:

[...]

> [RM] For backward compatibility: if the client did not indicate its capability for this feature it means it is a legacy client and it does not support it, so the server should not send the nonce to…

The text is not talking about sending the nonce--it's talking about sending the FORCERENEW_NONCE_CAPABLE option. Unless I read it wrong, it is saying the server SHOULD not advertise support unless the client has already indicated support.

> [RM] based on the procedure specified in section 21.5 of RFC 3315

It would help to say that in the text.

[...]

> [RM] based on the procedure specified in section 21.5 of RFC 3315

It would help to say that in the text.

> You mention this mechanism is vulnerable to MiTM attacks. Why is this okay? Are there some environments where it is good enough and others where it is not? (Also, do they really need to be MitM att…

You did not address this in your response. I think the "why is this okay" part is probably covered by other discussion, but the "do they really need to be MitM" question remains.

[...]

---

From: Ben Campbell <[email-masked]>
Date: Mon, 13 Feb 2012 15:06:16 -0600

> 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 th…

This is good information, and it would help to include it in the security considerations. I meant (but failed) to  comment in my original review that the security considerations would benefit from a more detailed discussion about the properties of the mechanism, and what attacks or vulnerabilities it is intended to mitigate. Your text above seems to do that.

> 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…

Do I infer correctly from your comment that the security properties of the mechanism don't really matter? That is, if the attacker we care about can't eavesdrop in the first place, does this really need to be an HMAC?

---

From: Ted Lemon <[email-masked]>
Date: Mon, 13 Feb 2012 21:21:32 +0000

On Feb 13, 2012, at 4:06 PM, Ben Campbell wrote:
Do I infer correctly from your comment that the security properties of the mechanism don't really matter? That is, if the attacker we care about can't eavesdrop in the first place, does this really need to be an HMAC?

Hm, I thought about that a bit more after I wrote my response.   The HMAC allows us to avoid sending the nonce in the clear in the DHCPFORCERENEW.   I don't think this adds any value from a security perspective, actually, even though it feels more comfortable.   I suspect it was put in in the original version simply because of that—why send a secret over the wire when you don't have to?   However, the original motivation for using the mechanism from RFC3315 was to avoid defining a new mechanism for a legacy protocol.   If we do need to change it, it's going to require a major rework of the document, and a lot of delay, so if it causes no harm, I think that's not worth doing.

I too would like to see the text I proposed added to the security considerations, so that we can be clear about what is being accomplished with this draft.

---

From: Ben Campbell <[email-masked]>
Date: Mon, 13 Feb 2012 15:25:01 -0600

> Hm, I thought about that a bit more after I wrote my response.   The HMAC allows us to avoid sending the nonce in the clear in the DHCPFORCERENEW.   I don't think this adds any value from a securit…

I concur it's probably not worth changing at this point--but it does inform the "is MD5 good enough" discussion, which might make it worth mentioning in the security considerations.

---

From: Maglione Roberta <[email-masked]>
Date: Tue, 14 Feb 2012 11:23:00 +0100

Hello Ted and Bell,
 I tried to address both your comments by combining your proposals:
Basically I added the text suggested by Ted in the security considerations section and then I slightly modified the introduction in order to clarify the applicability.
I've just posted version -04 that includes these changes together with the resolutions of some other comments we received during the review.
Please let me know if you have additional comments.
Thanks,
Regards,
Roberta

---

From: Ted Lemon <[email-masked]>
Date: Tue, 14 Feb 2012 13:52:40 +0000

On Feb 14, 2012, at 5:23 AM, Maglione Roberta wrote:
Please let me know if you have additional comments.

Thanks!   I think you should change this text in the introduction:

The mandatory authentication was
   originally motivated by a legitimate security concern whereby in some
   network environments DHCP messages can be spoofed and an attacker
   could more accurately guess the timing of DHCP renewal messages by
   first sending a FORCERENEW message.  However, in some networks native
   security mechanisms already provide sufficient protection against
   spoofing of DHCP traffic.  An example of such network is a Broadband
   Forum TR-101 [TR-101i2] compliant access network.  In such
   environments the mandatory coupling between FORCERENEW and DHCP
   Authentication [RFC3118] can be relaxed and a lighter authentication
   mechanism can be used for the FORCERENEW message.

To this:

[paragraph break]
The motivation for making authentication mandatory in DHCPFORCERENEW was to prevent an off-network attacker from taking advantage of DHCPFORCERENEW to accurately predict the timing of a DHCP renewal.   Without DHCPFORCERENEW, DHCP renewal timing is under the control of the client, and an off-network attacker has no way of predicting when it will happen, since it doesn't have access to the exchange between the DHCP client and DHCP server.

However, the requirement to use the DHCP authentication described in RFC3118 is more stringent than is required for this use case, and has limited adoption of DHCPFORCERENEW.   RFC3315 defines an authentication protocol using a nonce to prevent off-network attackers from successfully causing clients to renew.   Since the off-network attacker doesn't have access to the nonce, it can't trick the client into renewing at a time of its choosing.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 14 Feb 2012 14:11:20 -0600

Hi,

This is a followup on my Gen-ART review of draft-ietf-dhc-forcerenew-nonce-04, based on my previous review of version 03. In summary, this version is improved, but I still don't think it's ready for publication.

> [Note: Hopefully this draft has had or will have a SecDir review, since it seems ripe for significant security implications.]

I didn't see a comment about whether this happened. I still recommend a SecDir review if one has not yet occurred.

> I think some additional text in (perhaps in the security considerations) is needed to explain either why the vulnerability to eavesdroppers is either okay in general, or limits the mechanism's use…

This is improved by some changes to the introduction and the security considerations. But I still don't see a clear, normative statement about what environments this can be safely used in. I know Ted objected to Roberta's specific proposal, but I think to move forward this needs _some_ clear, concrete guidance about when to use or not to use it, or when 3118 authentication is more appropriate. Don't leave it up to the reader to draw the right conclusion.

> -- The mechanism appears to be limited to HMAC-MD5, and there does not appear to be any way of selecting other algorithms. Is HMAC-MD5 really sufficient as the only choice? Is there some expectatio…

There's a statement in the security considerations that "... security of the nonce in the case of on-link attacks isn't relevant." It would help drive the point home to add something to the effect that "Therefore HMAC-MD5 is by definition adequate for the purpose, and there is no need for an extensible HMAC mechanism."

> It's not clear to me what connection that assertion has with this draft. Is there an intent that the proposed mechanisms be used only in such environments? I don't find any language scoping this pr…

See comment under the first "major issue". I still think we need normative, concrete guidance about when to use or not to use this mechanism.

[...]

> Why not; what harm would it do? And on the other hand, if you want to discourage it, why not go all the way to "MUST NOT"?

I don't think my comment has been addressed by the discussion so far. I understand that the server should not insert a nonce unless the client has advertised support--but is it the author's intent that the server should not _advertise_ support unless the client has first advertised support?

Additionally, this update added the following text to the section:

> The 
> server SHOULD NOT include the nonce in an ACK when responding to
>    a renew unless a nonce was generated.  This minimizes the number of
>    times the nonce is sent over the wire.

I don't understand the first sentence. Don't include a nonce unless you generated it first? That seems like a tautology. Do you mean to say unless the nonce was sent in a previous message? Or unless a _new_ nonce was generated?

[...]

> Only if the client advertised it, right? Otherwise, this seems to conflict with the previous SHOULD NOT.

The text is updated, but it still conflicts with the previous statement in 3.1.3, paragraph 2 that says the server SHOULD NOT insert the option unless the client first inserted it. (See comment above).

[...]

> You mention this mechanism is vulnerable to MiTM attacks. Why is this okay? Are there some environments where it is good enough and others where it is not? (Also, do they really need to be MitM att…

The text still refers to a MiTM attacker. Do you mean "on-link" attacker? 

Otherwise, you've added text to motivate the mechanism for a specific use case. But I'd still like to see concrete guidance about when this draft is appropriate to use.

> I have trouble parsing this sentence. Are the propositions correct?

Partially fixed. Should "on the initial ACK" be "in the initial ACK"?

> Do you mean configured to "require", or configured to "use"? I would normally take "requires" to mean that the server would not work with clients that don't advertise support for the mechanism.

You changed the text from "configured to require" to "requires". I'm still confused on whether "requires" means that the server will refuse to service clients that don't advertise support. This is in contrast to "use", which would mean to me the server would invoke the option if the client supports it, but still work with clients that don't support it.

[...]