Hello Ben,
Thanks for reviewing this document.
Please see answers inline [RM]
Best regards,
Roberta
-----Original Message-----
From: Ben Campbell [mailto:ben(_at_)nostrum(_dot_)com]
Sent: martedì 7 febbraio 2012 0.17
To: draft-ietf-dhc-forcerenew-nonce(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org
Cc: gen-art(_at_)ietf(_dot_)org Review Team; The IETF
Subject: Gen-ART LC Review of draft-ietf-dhc-forcerenew-nonce-03
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.
[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."
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
-- 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 "
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.
[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.
-- 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.
[RM] I'll clarify the sentence
-- 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
-- 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."
Only if the client advertised it, right? Otherwise, this seems to conflict with
the previous SHOULD NOT.
[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:
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:
[RM] I'll address the following comments too.
-- 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?
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.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf