Additionally, the I got a failed delivery notice (User Unknow) for David Miles's address.
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.] > > > *** 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? > > > > > > _______________________________________________ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
