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

From: geopriv issue tracker ^lt;>
Date: Tue Aug 24 2010 - 17:16:28 EDT

#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


 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

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

 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

 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
 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: <>
geopriv <>
Geopriv mailing list
Received on Tue, 24 Aug 2010 21:16:28 -0000

This archive was generated by hypermail 2.1.8 : Tue Aug 24 2010 - 17:16:46 EDT