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

[Cullen Jennings <[e-mail]>]

I find the claim that attacks are easier to do with "VoIP  
Configuration Server Address" than the "TFTP Server Name" to be pretty  
dubious. All the devices I am aware of that use either option also get  
the DNS server from DHCP. If I can attack the DHCP response, I can  
probably get a DNS server running on the network and point the device  
at the alternative DNS server. If one is more secure than the other,  
it's not by much.

That said, I think this security discussion is going the wrong  
direction.  What is common practice, and what I think this should  
suggest, is that DHCP can be spoofed in some cases. The correct thing  
to do is to secure the object that is retrieved via tftp. One do  
things such as make sure it is signed such that the phone can verify  
it contains authorized data from correct source and if it contains any  
private data, like SIP passwords, that it is encrypted.  There are  
ways to mitigate DHCP spoofing but discussion of those is outside  
scope of this draft.

Suggesting the Auth option is a total non starter in every case I am  
aware of where this is used because the important thing is for this  
scheme to work when a new phone arrives without the administrator  
having to take the phone out of the box and enter a credential on the  
phone - the operational expense of something like this is just too  
high. Multiple manufactures resolve this by including factory  
installed public/private key pairs and certificates that bind the  
serial number of the phone and making sure the serial number of the  
phone is on a bar code on the outside of the box. The admin can then  
barcode scan the box, associate it with a given user, print a label  
for that user, ship the phone to that user, and when the user boots  
it, provide user specific data for the phone as well as replace the  
manufacture certificates with ones where the manufacture is not in the  
trust chain. Similar things are done for residential voice where the  
user enters the serial number of the phone and their credit care on  
the service providers web site and the service provider never has to  
touch the phone. They can ship from distributors to end users with no  
intermediate provisioning steps. One of the uses of this is firmload  
upgrades and many vendors have existing methods to check that code is  
appropriately signed.

Many phones from more vendors than just Cisco support variants of the  
above. The key things is that one can, and many do, implement secure  
systems even in environments where tftp is not secure.

Cullen, in my IETF participant role

PS. I am not aware of a single device that implements or uses this  
option that does not implement DNS. Certainly there are devices that I  
am not aware of but does anyone else have an example of one?  A more  
relevant concern might be that you want the phones to get their  
configuration from a differnt server than the diskless sun  
workstations and a separate option makes this a bit easier.


On Dec 3, 2008, at 4:29 AM, Ralph Droms (rdroms) wrote:

> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf

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