Re: secdir review of draft-raj-dhc-tftp-addr-option-04

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]