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