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:
[...]
-- 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.
[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."
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.
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.
[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
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.)
-- 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.
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:
[...]
-- 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"?
[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
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.
-- 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
It would help to say that in the text.
[...]
-- 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
It would help to say that in the text.
-- 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.)
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.
[...]
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf