Hi all,
In response to some feedback from the Security area during IESG
review, the
authors of draft-ietf-geopriv-lis-discovery have proposed a
modification to
the recommended authentication techniques. This email is soliciting
feedback from the working group on whether there are any objections to
the
proposed change.
Recall that a client discovers a LIS by getting a domain name from
DHCP and
finding a URI via a U-NAPTR lookup for that name. The question is: If
that
URI is HTTPS, what name should be checked against the name in the
certificate, the name from DHCP or the domain name in the URI? Prior
versions had recommended checking the name in the certificate against
the
name in the URI, i.e., the *output* of the U-NAPTR process. This
recommendation is counter to the advice in RFC 3958.
The authors' proposal is to change the document so that the
recommendation
is to check the authenticated name against the DHCP name (in accordance
with RFC 3958), and to provide some guidance for clients and networks in
how to make this process implementable with current libraries (many of
which only check the name in the URI). Detailed text is below.
If you have any comments on this proposal, please send them to the
list no
later than 09:00 US EST (GMT-4) on Thursday, 27 May 2010.
Thanks,
--Richard
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.
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
