------------------------------------------+---------------------------------
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/>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
