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