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

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 don't see why we would want to add "mandating the use of DHCP Auth",  
since that would go far beyond "describe the existing practice, don't  
try to change it in this document".

In short, I the current text seems to already address all of the  
points made except for mandating DHCP Auth, which is not in agreement  
with the spirit of RFC3942, since it would change the way in which the  
option is used.

/raj

On Dec 2, 2008, at 12:53 PM, John C Klensin wrote:

>
>
> --On Tuesday, 02 December, 2008 15:23 -0500 Ralph Droms
> <rdroms@cisco.com> wrote:
>
>> Sam - I think most of the issues in your review of
>> draft-raj-dhc-tftp-addr-option-04 can be resolved by reviewing
>> the purposes of RFC 3942 and publishing Informational RFCs
>> describing DHCP option codes.  Fundamentally, the reason to
>> publish RFCs under the process described in RFC 3942 is to
>> document existing uses of option codes in the range of option
>> codes reclaimed for assignment to new DHCP options.  The
>> concern is to avoid conflicts between new options and those
>> grandfathered ("hijacked") option codes.  As such, these RFCs
>> (usually Informational) simply document the already
>> ...
>> Responding to some of your specific points:
>>
>>>> At the very least, I suggest mandating the use of DHCP Auth
>>>> and   removing the suggestion to use option 66 to enhance
>>>> security.  And,   in the absence of a more data about how
>>>> widely used this option is,   I suggest not publishing this
>>>> document at all.
>>
>> The consensus of the dhc WG, to which I concur, is to publish
>> the document as Informational. The text in the Security
>> Considerations section about option 66 might be removed.
>> ...
>> To reiterate, it's not so much a question of whether a new
>> code point is needed; rather, according to the procedures
>> described in RFC 3942, this document gives a description of an
>> existing use of option code 150.  That option code is in use
>> ...
>
> Ralph,
>
> It seems to me that there is a middle ground here.   One can
> stick with Informational publication as the WG intends, but
> still modify the Security Considerations section, not only to
> remove the reference to option 66 (if there is consensus that is
> appropriate) but to add some explanation about why the use of
> this option without authentication might be problematic.
>
> Put differently, your objection to Sam's suggestion seems to
> hinge on "just describe the existing practice, don't try to
> change it in this document". Given RFC 3492, that is entirely
> reasonable.  But, if there are relatively obvious difficulties
> with that practice, it seems to me that documenting them would
> be helpful (indeed that not doing so borders on irresponsible).
>
>    john
>
>

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf