Subject: [Captive-portals] Discovering captive portal API URL via DNS?

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 4 Sep 2019 08:44:10 +0900

All,

During discussions with captive portal operators about implementing the
capport API, one of the stumbling blocks that keeps coming up is that the
captive portal operator does not always control the DHCP configuration and
thus cannot easily use RFC7710.

The WG has previously rejected the option of using a well-known DNS name to
discover the URL, because the API itself requires TLS, and without a
hostname it is not possible (or at least not easy) to validate the server.
However, what if the client did a CNAME query for capport.arpa (or
equivalent other local-only, non-DNSSEC-signed name), got back a CNAME for
the real server, and then assumed that the API server was
https://<targetofcname>/capport-api
?

Alternatively, Erik and Warren suggest RFC 7553. In this scheme the client
would do a URI lookup for "capport.arpa" or equivalent, and would take the
result of that URL as the API endpoint.

Thoughts?

Regards,
Lorenzo

---

From: "Cappalli, Tim (Aruba Security)" <[email-masked]>
Date: Wed, 4 Sep 2019 00:31:34 +0000

I like that idea, combined with well known. Ex: https://<targetofcname>/.well-known/capport-api/xyz<https://%3ctargetofcname%3e/.well-known/capport-api/xyz>

Ideally there would be some standardized precedence order as there are different cases for each of these. An example would be a common DNS a service that doesn’t have views-like functionality so the ability to return a different value based on the source IP/subnet may not be possible. In this case, the operator may have control of DHCP and could use 7710.

Tim

Tim Cappalli | Identity & Policy Architect | Aruba Security<https://www.arubanetworks.com/products/security/> | @timcappalli<https://twitter.com/timcappalli>

From: Captive-portals <[email-masked]> on behalf of Lorenzo Colitti <lorenzo=[email-masked]>
Date: Tuesday, September 3, 2019 at 4:45 PM
To: "[email-masked]" <[email-masked]>
Subject: [Captive-portals] Discovering captive portal API URL via DNS?

All,

During discussions with captive portal operators about implementing the capport API, one of the stumbling blocks that keeps coming up is that the captive portal operator does not always control the DHCP configuration and thus cannot easily use RFC7710.

The WG has previously rejected the option of using a well-known DNS name to discover the URL, because the API itself requires TLS, and without a hostname it is not possible (or at least not easy) to validate the server. However, what if the client did a CNAME query for capport.arpa (or equivalent other local-only, non-DNSSEC-signed name), got back a CNAME for the real server, and then assumed that the API server was https://<targetofcname>/capport-api<https://%3Ctargetofcname%3E/capport-api> ?

Alternatively, Erik and Warren suggest RFC 7553. In this scheme the client would do a URI lookup for "capport.arpa" or equivalent, and would take the result of that URL as the API endpoint.

Thoughts?

Regards,
Lorenzo

---

From: Erik Kline <[email-masked]>
Date: Tue, 3 Sep 2019 18:05:27 -0700

Chair hat off, co-author hat on.

We can certain craft some text to round out
https://tools.ietf.org/html/draft-ietf-capport-rfc7710bis-00#section-4 when
the time comes.  Certainly DHCP/RA would retain highest precedence.

RFC 7553 URI records would obviate the inevitable discussion about the
merits of .well-known (I know nothing about .well-known/ except that it
tends to bring up some (.)well-known responses).

Where would you slot DNS results relative to link relation in an HTTP
intercept/redirect?

On Tue, 3 Sep 2019 at 17:32, Cappalli, Tim (Aruba Security) <[email-masked]>
wrote:

> I like that idea, combined with well known. Ex:
> https://<targetofcname>/.well-known/capport-api/xyz
>
>
>
> Ideally there would be some standardized precedence order as there are
> different cases for each of these. An example would be a common DNS a
> service that doesn’t have views-like functionality so the ability to return
> a different value based on the source IP/subnet may not be possible. In
> this case, the operator may have control of DHCP and could use 7710.
>
>
>
> Tim
>
>
>
>
>
> *Tim Cappalli* *|* Identity & Policy Architect *|* Aruba Security
> <https://www.arubanetworks.com/products/security/> *|* @timcappalli
> <https://twitter.com/timcappalli>
>
>
>
> *From: *Captive-portals <[email-masked]> on behalf of
> Lorenzo Colitti <lorenzo=[email-masked]>
> *Date: *Tuesday, September 3, 2019 at 4:45 PM
> *To: *"[email-masked]" <[email-masked]>
> *Subject: *[Captive-portals] Discovering captive portal API URL via DNS?
>
>
>
> All,
>
>
>
> The WG has previously rejected the option of using a well-known DNS name
> to discover the URL, because the API itself requires TLS, and without a
> https://<targetofcname>/capport-api ?
>
>
>
> _______________________________________________
> Captive-portals mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/captive-portals
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 4 Sep 2019 10:08:30 +0900

If we have a way to discover the portal via DNS, then maybe we don't need
<link rel> at all? The problem with <link rel> is that it cannot be used
once the portal is open, so if the device logs in, and then disconnects and
reconnects, it doesn't work.

On Wed, Sep 4, 2019 at 10:05 AM Erik Kline <[email-masked]> wrote:

> https://tools.ietf.org/html/draft-ietf-capport-rfc7710bis-00#section-4
> when the time comes..  Certainly DHCP/RA would retain highest precedence.
>
>> Alternatively, Erik and Warren suggest RFC 7553. In this scheme the
>> client would do a URI lookup for "capport.arpa" or equivalent, and would
>> take the result of that URL as the API endpoint.
>>
>>
>>
>> Thoughts?
>>
>>
>>
>> Regards,
>>
>> Lorenzo

---

From: Erik Kline <[email-masked]>
Date: Tue, 3 Sep 2019 18:17:57 -0700

That's not strictly true (or it needn't be strictly true).

The text in #section-3 as worded allows for a portal that lets the
clear-text query through but still adds the API link rel into the
response.  If the text somehow doesn't allow this, we could make it more
explicit.

If there are 2 equally good ways to do this (DNS and link relation) then it
does, I grant, seem like it would be worth the time to see if the group
could scope it back down to one.

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 04 Sep 2019 12:46:38 +1000

What about those resolvers that collapse CNAME responses, effectively eliding them?

I assume that you are going to explicitly say that this has to be directed to the resolver provided in network configuration.  If that resolver is outside the network or less tightly secured than DHCP/RAs, then we have the possibility of attack on the DNS-over-UDP-53 that is used to get the CNAME response.

(Just contributin' not chairin'.)

On Wed, Sep 4, 2019, at 09:44, Lorenzo Colitti wrote:
> capport API, one of the stumbling blocks that keeps coming up is that 
> the captive portal operator does not always control the DHCP 
> configuration and thus cannot easily use RFC7710.
> 
> The WG has previously rejected the option of using a well-known DNS 
> name to discover the URL, because the API itself requires TLS, and 
> without a hostname it is not possible (or at least not easy) to 
> validate the server. However, what if the client did a CNAME query for 
> capport.arpa (or equivalent other local-only, non-DNSSEC-signed name), 
> got back a CNAME for the real server, and then assumed that the API 
> server was https://<targetofcname>/capport-api ?
> 
> client would do a URI lookup for "capport.arpa" or equivalent, and 
> would take the result of that URL as the API endpoint.
> 
> Thoughts?
> 
> Regards,
> Lorenzo

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 4 Sep 2019 12:32:24 +0900

Yes, the query would have to be directed to the resolver provided by
the network.

I agree that this could increases the attack surface compared to a
DHCP solution. DHCP is also a cleartext protocol, but it is typically
secured via other means like DHCP guard. If the network provides
equivalent protections to DNS traffic (most simply, by providing
strong protections against IP spoofing and on-link attacks), then the
security properties are likely equivalent.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 04 Sep 2019 03:27:18 -0400

> configuration and thus cannot easily use RFC7710.

Agreed.

    > would take the result of that URL as the API endpoint.

RFC7553 seems like a better choice than a CNAME hack.

So we are trading the assumption that captive portal operator can control
DHCP to one where captive portal operator can control/influence DNS, and
that things like DoT/DoH can not be used by the captive portal client.
(I just want to make the assumption explicit. I'm not complaining about it)

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 4 Sep 2019 17:00:41 +0900

> (I just want to make the assumption explicit. I'm not complaining about it)

That's not really an assumption - the fact that the captive portal client
can't do DoT/DoH is mostly true today, because unless the portal is open,
443 and 853 are likely to be blocked. By and large, DoT / DoH clients
probably already know not to attempt them on captive portals.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 04 Sep 2019 17:16:13 +0300

Lorenzo Colitti <[email-masked]> wrote:
    mcr>     that things like DoT/DoH can not be used by the captive portal
    mcr> client.  (I just want to make the assumption explicit. I'm not
    mcr> complaining about it)

    > That's not really an assumption - the fact that the captive portal
    > client can't do DoT/DoH is mostly true today, because unless the portal
    > is open, 443 and 853 are likely to be blocked. By and large, DoT / DoH
    > clients probably already know not to attempt them on captive portals.

Well, a captive portal could leave HTTPS to cloudflare open, the same way
that they might leave Do53 open to themselves, or to quadX.  That works today
for some portals.

And if the portal doesn't let just *any* Do53, but only to known public
resolvers (which they can even proxy if they want), then they can be sure to
defeat DNS-VPN mechanisms.

Some portals today *do* depend upon creating answers for names that aren't
real.  That fails today if you do DNSSEC validation.  Of course, some still
depend upon lying about all DNS requests, and but we have agreed that this is
bad.

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 04 Sep 2019 08:51:54 -0700

In general, I think that the code on a client system that is intentionally interacting with a Captive Portal (for discovery, etc), will need to use the locally-provisioned DNS. That is probably Do53, but could be DoT/DoH in the future; it would, however, be expected to be under the control of the portal if there is a portal present. Even if a system is strictly using DoT/DoH for other use cases, it needs to have some local exceptions for this kind of "system" traffic. A good example is the ipv4only.arpa lookup on DNS64 networks.

—Tommy

> On Sep 4, 2019, at 7:16 AM, Michael Richardson <[email-masked]> wrote:
> 
>

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 04 Sep 2019 09:00:27 -0700

> On Sep 3, 2019, at 4:44 PM, Lorenzo Colitti <lorenzo=[email-masked]> wrote:
> 
> All,
> 

Thanks for bringing this up.

I wanted to clarify the issue a bit before diving into the mitigations. Do these captive portal operators have *no* relationship to the DHCP configuration? Presumably, the captive portal enforcement is done somewhere on path, in the router, or between the router and the Internet connection. And, if there is redirection of DNS going on, presumably, this is a DNS server that the captive portal (or the operator of the network) has some control over, and is provisioned via DHCP. For such portals, I would assume that it would be as easy to add a DHCP CAPPORT option as it would be to add the DNS server address of the captive portal's resolver (assuming the DHCP implementation supports the option).

Since the mitigation below is specific to modifying the DNS, I assume that we are talking about captive portal solutions that work, in part, by intercepting DNS.

Thanks,
Tommy
> 
> The WG has previously rejected the option of using a well-known DNS name to discover the URL, because the API itself requires TLS, and without a hostname it is not possible (or at least not easy) to validate the server. However, what if the client did a CNAME query for capport.arpa (or equivalent other local-only, non-DNSSEC-signed name), got back a CNAME for the real server, and then assumed that the API server was https://<targetofcname>/capport-api ?
>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 04 Sep 2019 20:39:56 +0300

Tommy Pauly <tpauly=[email-masked]> wrote:
    > I wanted to clarify the issue a bit before diving into the
    > mitigations. Do these captive portal operators have *no* relationship
    > to the DHCP configuration? Presumably, the captive portal enforcement

I think that the issue is that the relationship is adversarial: different
silos.  The example that was given previously was that DHCP belonged to the
"desktop" group, while DNS belongs to the "network" group in some enterprise.
The DHCP all backends (via relays) to some DHCP servers, while the DNS
is operated by the "Internet" group.  That probably means that capport.arpa
(and ipv4.arpa) will get populated, and all of the non-captive desktops will
see that.  I think that this is okay.

    > Since the mitigation below is specific to modifying the DNS, I assume
    > that we are talking about captive portal solutions that work, in part,
    > by intercepting DNS.

I don't think that is necessarily the case.
The Internet group probably controls the routers, just not the DHCP.

---

From: Nicolas Mailhot <[email-masked]>
Date: Thu, 05 Sep 2019 09:08:58 +0200

> The Internet group probably controls the routers, just not the DHCP.

Dns, portal and network backbone control are inherently centralized 
setups, they can work together. DHCP is local-ish. It does not mesh well 
with the rest.

In fact, it would probably simplify a lot of things, if the portal was 
also a DoH node by default.

Regards,

-- 
Nicolas Mailhot