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

From: Ralph Droms <[email-masked]>
Date: Tue, 2 Dec 2008 15:23:51 -0500

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 established use of those  
option codes, so there are only very minimal requirements for  
demonstrating a need to record the use of the option code, and  
mandating changes to the established use of the option code is out-of- 
scope.  In the opinion of the dhc WG, this I-D meets the requirements  
of RFC 3942, which addresses your statement "It's not clear why a  
distinct code point is needed here" and the suggestions to require  
DHCP authentication, as well as the pointers to other, similar options  
are out-of-scope.

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.

>> It's not clear why a distinct code point is needed here.  The  
>> document
>> claims that the "TFTP server name" option (#66) must contain a domain
>> name, but I'm pretty sure that real-world devices (e.g. the Cisco
>> 7960) happily accept and use v4 address literals in option 66.
>> Furthermore, there appear to be other DHCP options that could do the
>> trick (e.g. #128, documented in the IANA registry as "TFTP Server IP
>> address (for IP Phone software load)").

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 today and, to eliminate any chance of  
conflict with a new option code in the future, it is entirely  
appropriate to record the use of the option code in the IANA registry  
and document its use.

>> The document's write-up says is "it is believed that to some extent  
>> this
>> option is in use in some deployments of VoIP devices".  That's not a
>> very convincing argument that enough devices use this to justify
>> invoking the RFC3942 procedure, given that other devices are making  
>> do
>> just fine with existing fields.

Richard checked internally at Cisco and got the following response  
from one of our colleagues:

   I would say that over 99% of Cisco Unified Communications Manager
   deployments use Option 150 with a small minority using Option 66.
   We do support Option 66, but it requires a DNS lookup if specified
   by name and does not allow for an array of addreses for the purposes
   of config server redundancy. Any third party phones that support
   registering with CUCM (e.g. Tandberg, Polycom, Sony, and others)
   also support using Option 150.

   Here's more information about uses of option 150 by Cisco customers  
(current as of 8/19/08):

	• 95,000+ Cisco Unified Communications customers (all using option 150)
	• 400+ customers deploying more than 5,000 IP phones
	• 18M+ IP Phones shipped

Also, there are two key differences between the "VoIP Configuration  
server address" option described in this document and other options:

* This option can carry a list of addresses, rather than just a single  
address.
* Cisco's use of the option will ultimately move toward using other
   protocols such as HTTP instead of TFTP, which is why the name was
   changed from "TFTP server address" to "VoIP Configuration server  
address".

>> And if we do want to proceed with defining this option: shouldn't it
>> also allow for v6 addresses?  (The current doc only allows for v4.)

As this document describes existing practice and does not define a new  
option, there is no need to describe a version of the option for  
DHCPv6 to carry IPv6 addresses.  Cisco expects to use a vendor- 
identifying vendor-specific option for the DHCPv6 version of this  
option.

- Ralph

On Nov 26, 2008, at Nov 26, 2008,2:58 AM, Samuel Weiler wrote:

> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should treat
> these comments just like any other last call comments.
>
> Summary:
>
> 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.
>
> Details:
>
> In 2004 RFC3942 defined a procedure for vendors to lay claim to DHCP  
> option code points that, while previously set aside for "site- 
> specific" options, had been used by vendors.  This document attempts  
> to claim such a code point.
>
> It's not clear why a distinct code point is needed here.  The document
> claims that the "TFTP server name" option (#66) must contain a domain
> name, but I'm pretty sure that real-world devices (e.g. the Cisco
> 7960) happily accept and use v4 address literals in option 66.
> Furthermore, there appear to be other DHCP options that could do the
> trick (e.g. #128, documented in the IANA registry as "TFTP Server IP
> address (for IP Phone software load)").
>
> The document's write-up says "it is believed that to some extent this
> option is in use in some deployments of VoIP devices".  That's not a
> very convincing argument that enough devices use this to justify
> invoking the RFC3942 procedure, given that other devices are making do
> just fine with existing fields.  Do these devices ALSO check option
> #66, such that continued use of #150 is really unnecessary?  In the
> four years since publication of RFC3942, have enough of these devices
> been obsoleted (or updated to also use other DHCP option fields) that
> this code point is no longer needed?
>
> And if we do want to proceed with defining this option: shouldn't it
> also allow for v6 addresses?  (The current doc only allows for v4.)
>
> The security considerations section cites rogue DHCP servers as attack
> vectors, but doesn't do enough to encourage the use of DHCP Auth.
> Furthermore, it suggests using the "TFTP server name" option, on the
> basis that a client must do a DNS lookup to use the contents, thereby
> giving an tiny extra layer of assurance.  I'm pretty sure that
> real-world devices happily accept v4 literals in option 66, making the
> suggestion a poor one.
>

_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: John C Klensin <[email-masked]>
Date: Tue, 02 Dec 2008 15:53:58 -0500

--On Tuesday, 02 December, 2008 15:23 -0500 Ralph Droms
<[email-masked]> 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
> grandfathered ("hijacked") option codes.  As such, these RFCs
> (usually Informational) simply document the already
>...
>>> 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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 02 Dec 2008 18:03:30 -0500

> be helpful (indeed that not doing so borders on irresponsible).

I'm inclined to agree with John here.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Jari Arkko <[email-masked]>
Date: Wed, 03 Dec 2008 12:39:49 +0200

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

---

From: Ralph Droms <[email-masked]>
Date: Wed, 3 Dec 2008 06:15:45 -0500

John - guess I wasn't clear in my reply.  I think it would be fine to  
include text suggesting the use of DHCP authentication.  Mandating  
authentication would be, in my opinion, out of scope.

To be clear, I don't see that there are, in practice, problems with  
the current deployment practice.  RFC 3118 was published several years  
ago, but deployment practice today uses other methods to mitigate the  
risk of DHCP server spoofing attacks.  Similar words about  
recommending the use of RFC 3118 authentication have been included in  
other RFCs, but RFC 3118 remains undeployed (and, in fact, mostly  
unimplemented).

- Ralph

---

From: Richard Johnson <[email-masked]>
Date: Tue, 2 Dec 2008 14:35:04 -0800

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

---

From: Samuel Weiler <[email-masked]>
Date: Tue, 2 Dec 2008 23:41:25 -0500 (EST)

...
> I'm inclined to agree with John here.

Likewise.

And thank you for providing the clarification on how widely this 
option is used.  Given that date, I withdraw the suggestion that the 
doc not be published.

-- Sam

---

From: Ralph Droms <[email-masked]>
Date: Wed, 3 Dec 2008 06:29:05 -0500

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:

> 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:

> 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.)
>

- Ralph

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 7 Dec 2008 12:18:37 -0700

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.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Sun, 07 Dec 2008 15:51:10 -0500

--On Sunday, December 07, 2008 12:18:37 PM -0700 Cullen Jennings 
<[email-masked]> wrote:

>
> I find the claim that attacks are easier to do with "VoIP Configuration
> Server Address" than the "TFTP Server Name" to be pretty dubious.

Me too.

> 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.

I'm inclined to agree with this, in principle.
In practice, that requires either preconfiguration, which sort of defeats 
the point of using DHCP, or a closed system like firmware updates signed by 
a device manufacturer, where not only the network but also the user and 
DHCP server operator are untrusted.

If we're talking about an option which will only ever be used to tell 
phones where to download new firmware, then this is fine.  If we're talking 
about an option which will be used by network operators to provide 
configuration to phones (in order to avoid manual configuration), or in 
general to provide a TFTP server address for whatever is the next step in 
the boot process, then "secure the object" sounds like good advice but IMHO 
is less practical than "configure your network to prevent DHCP spoofing".

> There are ways to mitigate DHCP spoofing but
> discussion of those is outside scope of this draft.

I agree that discussion of how to mitigate DHCP spoofing is out of scope. 
However, I think recommending that operators do so is appropriate.