ietf
[Top] [All Lists]

Followup Gen-ART Review on draft-ietf-dhc-forcerenew-nonce

2012-02-15 10:13:27
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.


On Feb 6, 2012, at 5:17 PM, Ben Campbell wrote:

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


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


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


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

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


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

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.

[...]



-- 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"?


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?

[...]


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

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

[...]



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

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.


*** Nits/editorial comments:

-- Abstract, second sentence:

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

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


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

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.

[...]

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf