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

[Ralph Droms <[e-mail]>]

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


_______________________________________________
secdir mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/secdir