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
-----Original Message-----
From: Ben Campbell [mailto:ben(_at_)nostrum(_dot_)com]
Sent: lunedì 13 febbraio 2012 22.06
To: Ted Lemon
Cc: Maglione Roberta;
draft-ietf-dhc-forcerenew-nonce(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org;
gen-art(_at_)ietf(_dot_)org Review Team; The IETF; Henderickx, Wim (Wim); Ullio
Mario
Subject: Re: Gen-ART LC Review of draft-ietf-dhc-forcerenew-nonce-03
On Feb 11, 2012, at 10:24 AM, Ted Lemon wrote:
[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."
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.
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.
[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.
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?
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