It is fixable.
All a client has to do is resolve an IP address and connect with one domain name ("lis.example.com"), then send a server name indication and authenticate using the other ("example.net").
But that's just in theory, reducing this to practice is less straightforward.
Both alternative-domain SNI and alternative-domain authentication are hard to implement. Support for those features in existing HTTP and TLS implementations is…patchy.
I'll share my solution:
1. Resolve "lis.example.com" to an IP address.
2. Add an entry to the hosts file for "example.net" and the IP address that you just got. (Or intentionally poison your local name resolution cache.)
3. Modify the LIS URI to include "example.net" instead of "lis.example.com".
4. Use the URI (make sure the client supports SNI)
5. Make sure to remove the hosts file entry when you are done.
YMMV: This interferes with any other uses you might have for "example.net". Since that's likely your local domain, that could be a problem ("xyz.example.net" would be unaffected).
--Martin
From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf Of Brian Rosen
Sent: Tuesday, 25 May 2010 11:22 PM
To: Thomson, Martin; Bernard Aboba; acooper@cdt.org; geopriv@ietf.org
Subject: Re: [Geopriv] Security considerations for LIS discovery
I am struggling a bit in understanding the problem.
Let's start with why DHCP returns example.net and UNAPTR leads to lis.example.com. Why is that not fixable? What is hard about getting consistency in the domain names?
Having said that, SRV works for SIP. Certainly, the server at the site mentioned in the SRV entry could have a cert in exactly that name.
Brian
On 5/24/10 7:04 PM, "Thomson, Martin" <Martin.Thomson@andrew.com> wrote:
In short, it's really hard to implement otherwise.
The IESG were not comfortable with the idea that we were relying on the integrity of the DNS. The exception granted to LoST was only acceptable because of the deployment model. Implementation challenges were insufficient justification for another such exception.
--
DHCP returns "example.net"; UNAPTR leads to "lis.example.com". RFC 3958 says that you authenticate the server at "lis.example.com" and ensure that its certificate says "example.net". Sounds easy. In practice it isn't.
This leads to an implementation/deployment deadlock. Ideally, a deployment can use different domains, and a client is able to authenticate those domains. In practice, that's not feasible.
HTTP implementations (and even TLS implementations) struggle to correctly authenticate a domain based on the hostname used to reach it. A number of implementations that support TLS ignore the authentication part entirely. Some HTTP/TLS implementations are flexible enough to allow a user access to the parts that would let them roll their own authentication, but others do not. Even if there is the possibility, implementing authentication as described in RFC 3958 is a non-trivial exercise.
Furthermore, there are complications that make this even more uncertain. For a LIS that serves multiple domains, the easiest way to address this is to add multiple domain names into subjectAltName. However, that doesn't scale well, and it certainly isn't a cheap option, particularly when you need to add domains.
A more flexible approach would be to rely on the TLS server name indication, but it's unclear what the implications are. Furthermore, the implementation problems above extend to server name indication support. Few enough implementations support server name indication, and even fewer could resolve one DNS name and authenticate on a different name.
--
We chose to allow implementations to ignore all this complexity and in doing so, constrain how networks are deployed.
The alternative is to give up on U-NAPTR. And that's why Richard is bringing this back here. I'd personally prefer not to.
There's also a hope that we can resolve this problem in another way. The problem is an old one, and one that we should be able to solve without all this complexity and mess. I hear that there's a BoF being prepared on a very similar subject.
--Martin
From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: Tuesday, 25 May 2010 3:35 AM
To: acooper@cdt.org; geopriv@ietf.org
Subject: Re: [Geopriv] Security considerations for LIS discovery
"
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.
"
Isn't this overly restrictive? If this constraint were always to be enforced, why would we need U-NAPTR in the first place?
> From: acooper@cdt.org
> To: geopriv@ietf.org
> Date: Mon, 24 May 2010 18:24:33 +0100
> Subject: [Geopriv] Security considerations for LIS discovery
>
> [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
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
