Subject: Re: [Geopriv] [geopriv] #23: Good Security of DHCP

From: "geopriv issue tracker" <[email-masked]>
Date: Tue, 19 Jan 2010 22:42:41 -0000

#23: Good Security of DHCP
---------------------------------------+------------------------------------
 Reporter:  Hannes.Tschofenig@…        |        Owner:  Hannes.Tschofenig@…       
     Type:  enhancement                |       Status:  closed                    
 Priority:  major                      |    Milestone:  draft-ietf-geopriv-3825bis
Component:  rfc3825bis                 |      Version:                            
 Severity:  Active WG Document         |   Resolution:  fixed                     
 Keywords:                             |  
---------------------------------------+------------------------------------
Changes (by bernard_aboba@…):

  * status:  new => closed
  * resolution:  => fixed
  * severity:  - => Active WG Document

Comment:

 The current text of the security considerations section addresses
 potential disclosure risks as well as modification attacks.  I will add
 some advice on use of link level encryption in -06.

 "Where critical decisions might be based on the value of this GeoConf
 option, DHCP authentication as defined in "Authentication for DHCP
 Messages" [RFC3118] and "Dynamic Host Configuration Protocol for IPv6
 (DHCPv6)" [RFC3315] SHOULD be used to protect the integrity of the DHCP
 options.

 Since there is no privacy protection for DHCP messages, an
 eavesdropper who can monitor the link between the DHCP server and
 requesting client can discover this LCI.

 To minimize the unintended exposure of location information, the LCI
 option SHOULD be returned by DHCP servers only when the DHCP client
 has included this option in its 'parameter request list' (section 3.5
 [RFC2131]).

 When implementing a DHCP server that will serve clients across an
 uncontrolled network, one should consider the potential security
 risks."

-- 
Ticket URL: <http://wiki.tools.ietf.org/wg/geopriv/trac/ticket/23#comment:3>
geopriv <http://tools.ietf.org/geopriv/>

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 19 Jan 2010 18:36:01 -0600

At 04:42 PM 1/19/2010, geopriv issue tracker wrote:
>Reporter:  Hannes.Tschofenig@…        | 
>Owner:  Hannes.Tsschofenig@…            Type: 
>enhancement                 |       Status: 
>closed                    Priority:  major 
>                |    Milestone: 
>draft-ietf-geopriv-3825bis 
>Component:  rfc3825bis                 | 
>Version:                            Severity: 
>Active WG 
>Document         |   Resolution:  fixed 
>            Keywords: 
>  | 
>Changes (by bernard_aboba@…):   * stattus:  new 
>=> closed   * resolution:  => fixed   * 
>severity:  - => Active WG Document Comment: The 
>current text of the security considerations 
>section addresses potential disclosure risks as 
>well as modification attacks.  I will add some 
>advice on use of link level encryption in -06. 
>"Where critical decisions might be based on the 
>value of this GeoConf option, DHCP 
>authentication as defined in "Authentication for 
>DHCP Messages" [RFC3118] and "Dynamic Host 
>Configuration Protocol for IPv6 (DHCPv6)" 
>[RFC3315] SHOULD be used to protect the 
>integrity of the DHCP options. Since there is no 
>privacy protection for DHCP messages, an 
>eavesdropper who can monitor the link between 
>the DHCP server and requesting client can 
>discover this LCI. To minimize the unintended 
>exposure of location information, the LCI option 
>SHOULD be returned by DHCP servers only when the 
>DHCP client has included this option in its 
>'parameter request list' (section 3.5 [RFC2131]).

wrt the above "when":

s/when/after

IMO this makes the statement more direct and to the point.

>When implementing a DHCP server that will serve 
>clients across an uncontrolled network, one 
>should consider the potential security risks."

I assume that for controlled networks -- this doesn't apply?

James

>  -- Ticket URL: 
> <http://wiki.tools.ietf.org/wg/geopriv/trac/ticket/23#comment:3> 
> _______________________________________________ 
> Geopriv mailing list [email-masked] 
> https://www.ietf.org/mailman/listinfo/geopriv

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 19 Jan 2010 18:47:11 -0800

> IMO this makes the statement more direct and to the point.

Yes, it's more clear. 

> I assume that for controlled networks -- this doesn't apply?

I suppose that depends on what "uncontrolled" means.   My (perhaps incorrect) assumption was that "uncontrolled" meant a network that did not employ security mechanisms such as link layer security or even packet filtering.  Perhaps another term might be appropriate? 

The security risks discussed in the section include disclosure and packet modification.  

The section advocates use of DHCP authentication to address packet modification threats. 

In -06, I inserted a sentence to address the disclosure aspect:
"Link layer confidentiality may also be employed to reduce the risk of location disclosure."

Which begs the question of what additional potential security risks the sentence is advocating that we consider.

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 19 Jan 2010 22:17:25 -0600

At 08:47 PM 1/19/2010, Bernard Aboba wrote:
>I suppose that depends on what "uncontrolled" means.   My (perhaps 
>incorrect) assumption was that "uncontrolled" meant a network that 
>did not employ security mechanisms such as link layer security or 
>even packet filtering.  Perhaps another term might be appropriate?

I was thinking more along the lines of SMB/enterprise vs. SP 
environments, where one is generally (significantly) more often 
controlled than the other (but not in every case).

>Which begs the question of what additional potential security risks 
>the sentence is advocating that we consider.

this might be opening up pandora's box here, so let's keep this 
between just you and me...

;-)

is the 'link layer confidentiality' you're thinking of L2 hop-by-hop, 
or between the endhost and the first L3 node?  One or two multipart 
sentence(s) could address both cases, if you want to expound on this point.

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 20 Jan 2010 12:38:46 +0800

> between just you and me...

Rather than open that box, why not close it and remove this entirely:

   risks.

There's sufficient specific advice already.  This doesn't really add anything that can be acted upon directly; it's sort of vague.

> ... you're thinking of L2 hop-by-hop, 
> or between the endhost and the first L3 node...

I don't see a great deal of value in belabouring the point, unless we're aware of a specific attack.  We've already highlighted the disclosure problem - if the network uses hop-by-hop confidentiality, then I'd hope that it would be clear that any hops can get the data.

--Martin

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 19 Jan 2010 23:11:13 -0600

At 10:38 PM 1/19/2010, Thomson, Martin wrote:
>There's sufficient specific advice already.  This doesn't really add 
>anything that can be acted upon directly; it's sort of vague.
>
>I don't see a great deal of value in belabouring the point, unless 
>we're aware of a specific attack.  We've already highlighted the 
>disclosure problem - if the network uses hop-by-hop confidentiality, 
>then I'd hope that it would be clear that any hops can get the data.

I agree with each point made here

James