ietf
[Top] [All Lists]

Re: Gen-ART LC Review of draft-ietf-dhc-forcerenew-nonce-03

2012-02-13 10:03:52
[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.

[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.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf