Protocol Action: 'Discovering the Local Location Information Server (LIS)' to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



The IESG has approved the following document:

- 'Discovering the Local Location Information Server (LIS) '
   <draft-ietf-geopriv-lis-discovery-15.txt> as a Proposed Standard


This document is the product of the Geographic Location/Privacy Working Group. 

The IESG contact persons are Robert Sparks and Gonzalo Camarillo.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-lis-discovery-15.txt

Technical Summary:

This document describes a method for the discovery of a Location
Information Server (LIS) in the access network serving a device.
Discovery of the correct LIS in the local access network is necessary
for devices that wish to acquire location information from the
network. The method described defines Dynamic Host Configuration
Protocol (DHCP) options for IP versions 4 and 6 that specify a domain
name. This domain name is then used as input to a URI-enabled NAPTR (U-
NAPTR) resolution process.

Working Group Summary:

This document represents the consensus of the GEOPRIV working group.
The original drafts of this document contained several different
methods of performing LIS discovery. Through the working group review
process, the DHCP/U-NAPTR method outlined in the current document was
selected as the most appropriate for standardization at the current
time.

Document Quality:

The key decision in drafting this document was to craft the LIS
discovery mechanism in a near-identical fashion to the server
discovery process outlined in RFCs 5222 and 5223, which had already
been thoroughly vetted.


RFC Editor Note

OLD:
  U-NAPTR is entirely dependent on its inputs.  In falsifying a domain
  name, an attacker avoids any later protections, bypassing them entirely.


  To ensure that the access network domain name DHCP option can be relied

  upon, preventing DHCP messages from being modified or spoofed by
  attackers is necessary.  Physical or link layer security are commonplace


  methods that can reduce the possibility of such an attack within an
  access network; alternatively, DHCP authentication [RFC3118] can provide


  a degree of protection against modification or spoofing.

  The domain name that is used to authenticated the LIS is the domain
name
  in the URI that is the result of the U-NAPTR resolution.  Therefore, if
  an attacker were able to modify or spoof any of the DNS records used in
  the DDDS resolution, this URI could be replaced by an invalid URI.  The
  application of DNS security (DNSSEC) [RFC4033] provides a means to limit


  attacks that rely on modification of the DNS records used in U-NAPTR
  resolution.  Security considerations specific to U-NAPTR are described
  in more detail in [RFC4848].

  An "https:" URI is authenticated using the method described in Section
  3.1 of [RFC2818].  The domain name used for this authentication is the
  domain name in the URI resulting from U-NAPTR resolution, not the input
  domain name as in [RFC3958].  Using the domain name in the URI is more
  compatible with existing HTTP client software, which authenticate
  servers based on the domain name in the URI.

NEW:
  The domain name that used to authenticate the LIS is the domain name
  input to the U-NAPTR process, not the output of that process [RFC3958],
  [RFC4848].  As a result, the results of DNS queries do not need
  integrity protection.

  An "https:" URI is authenticated using the method described in Section
  3.1 of [RFC2818].  HTTP client implementations frequently do not provide


  a means to authenticate a based on a domain name other than the one
  indicated in the request URI, namely the U-NAPTR output.  To avoid
  having to authenticate the LIS with a domain name that is different to
  the one used to identify it, a client MAY choose to reject URIs that
  contain a domain name that is different to the U-NAPTR input.  To
  support endpoints that enforce the above restriction on URIs, network
  administrators SHOULD ensure that the domain name in the DHCP option is
  the same as the one contained in the resulting URI.

  Authentication of a LIS relies on the integrity of the domain name
  acquired from DHCP.  An attacker that is able to falsify a domain name
  circumvents the protections provided.  To ensure that the access network


  domain name DHCP option can be relied upon, preventing DHCP messages
  from being modified or spoofed by attackers is necessary.  Physical or
  link layer security are commonplace methods that can reduce the
  possibility of such an attack within an access network.  DHCP
  authentication [RFC3118] might also provide a degree of protection
  against modification or spoofing.

_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce


[Index of Archives]     [IETF]     [IETF Discussion]     [Linux Kernel]

  Powered by Linux