Jari - I agree that mentioning security issues, pointing to the
Security Considerations in RFC 2131 and citing RFC 3118, is appropriate.
Responding to Richard...
On Dec 2, 2008, at Dec 2, 2008,5:35 PM, Richard Johnson wrote:
Ok, maybe I'm not understanding what's being suggested or maybe I'm
simply reading the existing text in a different way. Here's the
contents of the draft's "Security Considerations" section:
A rogue DHCP Server could use this option in order to coerce a
Client
into downloading configuration from an alternate Configuration
Server
and thus gain control of the device's configuration. This is more
easily done with the VoIP Configuration Server Address option
than it
was with the "TFTP Server Name" option, because in the latter case
the attack would need to control DNS responses as well as inserting
the rogue DHCP option information. If this is a concern, then
either
DHCP Authentication may be used, or the "TFTP Server Name" option
may
be used instead.
Message authentication in DHCP for intradomain use where the out-
of-
band exchange of a shared secret is feasible is defined in
[RFC3118].
Potential exposures to attack are discussed in section 7 of the
DHCP
protocol specification in [RFC2131].
Other out-of-band methods of verifying the validity of the VoIP
Configuration Server Address, such as certificates of trust,
could be
used to mitigate some security concerns.
So, it only mentions option 66 ("TFTP Server Name" option) by
comparison and in order to point out the relative levels of security
involved. It has no "suggestion to use option 66".
The text already has an "explanation about why the use of this
option without authentication might be problematic". As a matter of
fact, it seems rather explicit on the matter.
I suggest we elide the first paragraph Richard quoted, and leave the
remainder unchanged ... except for fixing what appears to be a typo in
the first sentence of the second paragraph: s/is feasible is/is
feasible as/
Jeff Hutzelman mentioned other common techniques for mitigating the
risk from DHCP server spoofing attacks, which have not, to date, been
mentioned in any other DHCP RFCs. If there is serious interest in a
review of DHCP security practices, the dhc WG could return to its work
on a DHCP threat analysis and BCP for threat mitigation.
On Dec 3, 2008, at Dec 3, 2008,5:39 AM, Jari Arkko wrote:
I think John's advice is solid. We really need to document the
properties of our specifications, including being very clear about
the shortcomings and recommended workarounds. Truth in advertising.
(However, I'd would avoid making mandatory-to-implement changes that
do not match with codebase for a legacy option document such as this
is.)
I'm expecting a draft revision.
Jari
- Ralph
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf