Subject: [Geopriv] [geopriv] #37: Section 3

From: "geopriv issue tracker" <[email-masked]>
Date: Tue, 10 Aug 2010 21:07:51 -0000

#37: Section 3
------------------------------------------+---------------------------------
 Reporter:  bernard_aboba@…               |       Owner:  bernard_aboba@…           
     Type:  defect                        |      Status:  new                       
 Priority:  major                         |   Milestone:  draft-ietf-geopriv-3825bis
Component:  rfc3825bis                    |     Version:  1.0                       
 Severity:  Waiting for Shepherd Writeup  |    Keywords:                            
------------------------------------------+---------------------------------
 draft-thomson-geopriv-3825bis contained some material relating to
 security which was not included within RFC 3825bis.  For example,
 Section 1 states:

    This document only defines the delivery of location information from
    the DHCP server to the client, due to security concerns related to
    using DHCP to update the database.  Within the GEOPRIV architecture
    as defined by RFC 3693 [RFC3693], the defined mechanism in this
    document for conveying initial location information is known as a
    "sighting" function.  Sighting functions are not required to have
    security capabilities and are only intended to be configured in
    trusted and controlled environments.  (A classic example of the
    sighting function is a Global Positioning System wired directly to a
    network node.)  Further discussion of the protections that must be
    provided according to RFC 3694 [RFC3694] are in the Security
    Considerations section of this document (Section 4).

 Section 4 reads as follows:

 Security considerations related to the privacy of location
 information as discussed in the GEOPRIV documents RFC 3693 [RFC3693]
 and RFC 3694 [RFC3694] apply.

 Where critical decisions might be based on the value of this option,
 DHCPv4 authentication in RFC 3118 [RFC3118] 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 option. Thus, usage of the
 option on networks without access restrictions or network-layer or
 link-layer privacy protection is NOT RECOMMENDED.

 To minimize the unintended exposure of location information, the
 "GEOCONF_GEODETIC" option SHOULD be returned by DHCPv4 servers only
 when the DHCPv4 client has included this option in its 'parameter
 request list' (RFC 2131 [RFC2131], Section 3.5). Similarly, the
 "OPTION_GEOCONF_GEODETIC" option SHOULD be returned by DHCPv6 servers
 only when the DHCPv6 client has included this option in its
 "OPTION_ORO".

 After initial location information has been introduced, it MUST be
 afforded the protections defined in RFC 3694 [RFC3694]. Therefore,
 location information SHOULD NOT be sent from a DHCP client to a DHCP
 server. If a client decides to send location information to the
 server, it is implicitly granting that server unlimited retention and
 distribution permissions.

 [BA] Would any of this material be useful to include in RFC 3825bis?

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/geopriv/trac/ticket/37>
geopriv <http://tools.ietf.org/geopriv/>

---

From: "geopriv issue tracker" <[email-masked]>
Date: Wed, 11 Aug 2010 04:34:08 -0000

#37: Section 3

Comment(by martin.thomson@…):

 A lot of the text cited in this issue is lifted directly from RFC 4776.  I
 tend to think that most of it is a too wordy.

 What is potentially of use is the citation of RFC 3693.  The rest of the
 actual concerns are covered to some extent already, albeit in a cursory
 fashion.

 A fault that both sets of text share is an overly strong reliance on
 "SHOULD".  There is little guidance to an implementer on what sort of
 reasons might be acceptable for ignoring the "SHOULD".

 The first SHOULD applies to RFC 3118, so we can take it as read that it
 will be ignored; the second SHOULD talks about not providing location
 unless requested, which I think can be addressed by allowing servers to
 have some prior knowledge about clients.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/geopriv/trac/ticket/37#comment:1>
geopriv <http://tools.ietf.org/geopriv/>

---

From: "geopriv issue tracker" <[email-masked]>
Date: Tue, 24 Aug 2010 21:16:28 -0000

#37: Section 3
------------------------------------------+---------------------------------
 Reporter:  bernard_aboba@…               |        Owner:  bernard_aboba@…           
     Type:  defect                        |       Status:  closed                    
 Priority:  major                         |    Milestone:  draft-ietf-geopriv-3825bis
Component:  rfc3825bis                    |      Version:  1.0                       
 Severity:  Waiting for Shepherd Writeup  |   Resolution:  fixed                     
 Keywords:                                |  
------------------------------------------+---------------------------------
Changes (by bernard_aboba@…):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Here is a potential change to Section 3 to include references to RFC 3693
 and 3694, as well as to address the tampering as well as confidentiality
 issues:

 Geopriv requirements (including security requirements) are discussed in
 "Geopriv Requirements" [RFC3693].
 A threat analysis is provided in "Threat Analysis of the Geopriv Protocol"
 [RFC3694].

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

 Where critical decisions might be based on the value of this
 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.

 Link layer confidentiality and integrity protection may also be employed
 to reduce the
 risk of location disclosure and tampering.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/geopriv/trac/ticket/37#comment:2>
geopriv <http://tools.ietf.org/geopriv/>

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 24 Aug 2010 17:55:50 -0500

At 04:16 PM 8/24/2010, geopriv issue tracker wrote:
>€¦                Type:  defect 
>       |       Status:  closed 
>Component:  rfc3825bis                    | 
>Version:  1.0                       Severity: 
>Waiting for Shepherd 
>Writeup  |   Resolution:  fixed 
>    Keywords:                                | 
>Changes (by bernard_aboba@…):    * status:  new 
>=> closed   * resolution:  => fixed Comment: 
>Here is a potential change to Section 3 to 
>include references to RFC 3693 and 3694, as well 
>as to address the tampering as well as 
>confidentiality issues: Geopriv requirements 
>(including security requirements) are discussed 
>in "Geopriv Requirements" [RFC3693]. A threat 
>analysis is provided in "Threat Analysis of the 
>Geopriv Protocol" [RFC3694]. 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]). Where critical decisions might be 
>based on the value of this 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.

I have no issues with what's above (even if the 
formatting didn't translate very well here. I 
think I have 1 issue with what's below though...

>Link layer confidentiality and integrity 
>protection may also be employed to reduce the 

I don't care for the "may" that's here in this 
sentence.  If this is for implementers it should 
be a MAY, if it's here for education or configuration it should be a "can".

IMO of course

James

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

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 24 Aug 2010 16:11:55 -0700

> be a MAY, if it's here for education or configuration it should be a "can".

It does seem odd to me that RFC 3118 is a SHOULD while link layer security is not even a MAY.  Note that while I added "and integrity" to the last sentence, I didn't change the capitalization.  

Earlier, Martin had questioned some of the SHOULDs:

"A fault that both sets of text share is an overly strong reliance on 
"SHOULD".  There is little guidance to an implementer on what sort of 
reasons might be acceptable for ignoring the "SHOULD". The first SHOULD applies to RFC 3118,
 so we can take it as read that it will be ignored; the second SHOULD 
talks about not providing location unless requested, which I think can 
be addressed by allowing servers to have some prior knowledge about 
clients."

Here is a (better formatted) version of the proposed text.  

3.  Security Considerations

   Geopriv requirements (including security requirements) are discussed
   in "Geopriv Requirements" [RFC3693].  A threat analysis is provided
   in "Threat Analysis of the Geopriv Protocol" [RFC3694].

   Where critical decisions might be based on the value of this 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.

   Link layer confidentiality and integrity protection may also be
   employed to reduce the risk of location disclosure and tampering.

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 24 Aug 2010 18:29:39 -0500

At 06:11 PM 8/24/2010, Bernard Aboba wrote:
>It does seem odd to me that RFC 3118 is a SHOULD while link layer 
>security is not even a MAY.  Note that while I added "and integrity" 
>to the last sentence, I didn't change the capitalization.

I remember having to talk Allison out of mandating RFC 3118 as a MUST 
when writing 3825, and "got away with" it only being a SHOULD, 
knowing full well this wouldn't be implemented or configured very 
often in the real world.

I think the lowercase "may" in the last sentence ought to be a "can" 
instead, mostly because IETF doesn't regularly mandate link layer 
technologies be a certain way in order for an IETF technology's use.

IMO of course.

James

>"A fault that both sets of text share is an overly strong reliance 
>on "SHOULD". There is little guidance to an implementer on what sort 
>of reasons might be acceptable for ignoring the "SHOULD". The first 
>SHOULD applies to <http://tools.ietf.org/html/rfc3118>RFC 3118, so 
>we can take it as read that it will be ignored; the second SHOULD 
>talks about not providing location unless requested, which I think 
>can be addressed by allowing servers to have some prior knowledge 
>about clients."
>