On May 24, 2010, at 11:24 AM, Alissa Cooper wrote:
> [Sending on behalf of Richard whose email is down.]
>
> 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
Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
