Subject: [Captive-portals] Fixing RFC 7710

From: Martin Thomson <[email-masked]>
Date: Fri, 2 Mar 2018 14:58:24 +1100

We've had a number of discussions in the captive portals group about
fixing RFC 7710.

Erik and I would like to propose a plan for that work.  We would keep
this to addressing the issues that we have identified thus far.
Namely:

1. The purpose of the URI is not well defined.  We would reference the
capport architecture and API documents for that.  The group would need
to decide between:
  a. point to the API
  b. point to a login page

2. There isn't a clear way to signal that there is no captive portal
in the network.  It has been suggested that we use a special URL -
e.g., urn:ietf:params:capport:unrestricted. Alternatively, we could
privilege the empty string, but that doesn't have as clear a signal of
intent.

3. RFC 7710 states that the URL SHOULD use an address literal.  This
works at odds with the idea of using HTTPS.

Is there anyone who is willing to take on this work?  We aim to start
and complete this work in <1 meeting cycle, starting in London.

For the authors of RFC 7710, let us know if you have any concerns.

---

From: Alexander Roscoe <[email-masked]>
Date: Fri, 2 Mar 2018 10:53:01 -0500

I always assumed the captive portal URL could function as the API
endpoint as well. For example, if the captive portal url is
'https://mycaptiveportal.com/index.html' then the API could port to
the same URL at index.html. Another solution could take the root part
of the URL and then attach the known URI at the end.

I believe a URL should be transported in the DHCP / RA as it needs to
support HTTPS.  There are work arounds with doing 302s but it then
becomes more steps to develop. I think RFC7710 is easy to implement
for most venders in their DHCP software.  Because of that, it acts as
a stepping stone into further enhancements.

>From an implementation point of view, nothing needs to change the
captive portal to support the DHCP / RA option which really make it
easy to enable.

On Thu, Mar 1, 2018 at 10:58 PM, Martin Thomson
<[email-masked]> wrote:
> _______________________________________________
> Captive-portals mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/captive-portals

-- 
Alexander Roscoe
484-716-9048

---

From: Michael Richardson <[email-masked]>
Date: Fri, 02 Mar 2018 16:41:34 -0500

> this to addressing the issues that we have identified thus far.

Hi, so are you considering 7710bis, or a document that just Updates 7710?
7710bis seems excessive to me, unless you think that we have to change the
DHCP/RA option codes in the process.

    > to decide between: a. point to the API b. point to a login page

Could the API document do the required updates?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Fri, 2 Mar 2018 16:58:57 -0500

> We've had a number of discussions in the captive portals group about

Fixing or make RFC7710 more useful ?

> capport architecture and API documents for that.  The group would need
Our (or at least my thought) was in the beginning,
just send the device to the location of the portal, as I hate having
connections intercepted.
Then the USER could just see that page and decide what to do.

Now you are taking that basic idea forward to allow a handshake between
device and portal ; this is good
Happy to help with that anything that allows [semi/fully]-automated sign-on
is great.

> This seems to be a standard problem in DHCP i.e. there is no way to issue
a denial or list available options

> works at odds with the idea of using HTTPS.

If there is a better way then this is the reason to do an RFC7710-bis,
the items above only need to CITE RFC7711, and there could be more than one
API proposed/documented.

> This is a great goal, willing to review

> For the authors of RFC 7710, let us know if you have any concerns.

not really, thanks for pushing the idea forward.

Olafur

---

From: Warren Kumari <[email-masked]>
Date: Fri, 2 Mar 2018 17:52:02 -0500

> We've had a number of discussions in the captive portals group about

As one of the original authors of RFC 7710, I fully support this!

> privilege the empty string, but that doesn't have as clear a signal of

Oooh, I like the special URL idea -- initially the thought was a combination of:

1: Until this is ubiquitously deployed (ha!), devices will need to do
CP heuristics, and so will discover the lack of CP through that.
2: If there is no CP, no-one is likely to include the option.
3: Since the vast majority of networks don't use CPs, is this an undue
burden on them?

> works at odds with the idea of using HTTPS.

Yeah, there was a significant amount of discussion on this at the time
of the original document -- I can probably dredge it up if needed, but
IIRC, it focused around the fact that 1: many clients behind a CP
would not have enough working connectivity to be able to do the DNS
stuff required to be able to validate the cert, and 2: a lack of
clarity on what exactly would be authenticated.

I'm at Washington Dulles airport, connect to the IAD_Free_WiFi SSID
and get a URL of https://www.your-preferred-internet-provider.com

1: The cert is likely to filled with such guff as:
 URI:http://cdp.rapidssl.com/RapidSSLRSACA2018.crl
 CPS: https://www.digicert.com/CPS
 OCSP - URI:http://status.rapidssl.com
 CA Issuers - URI:http://cacerts.rapidssl.com/RapidSSLRSACA2018.crt

Many clients have static / corporate DNS servers configured -- does
the CP operator simply allow any port 53 traffic so that the user can
resolve these? If so (fairly obviously), people who want to bypass the
CP will simply DNS tunnel all traffic.
Also, does the CP operator know which IPs cdp.rapidssl.com and
status.rapidssl.com will live behind on e.g Thursday? Or do they need
to constantly resolve URLs in the cert and dynamically allow access to
OSCP / CRL servers? Or does the CP also need to OSCP stale?

2: How does the client know that your-preferred-internet-provider.com
is the identity which *should* be providing Internets? Having the
client accept that /might/ give the impression that there is some
*reason* to believe this, and was viewed as a usability concern --
training users / developers to make a leap of trust that "you should
trust this identity is the right one" was viewed as a dangerous
pattern.

Somehow this turned into "Just ship http://192.168.1.1/foo and then
that, um, someone else's problem"  -- before everyone jumps down my
throat, I'm not arguing for or against the positions, rather trying to
provide some background on how we ended up here. :-P

> and complete this work in <1 meeting cycle, starting in London.

I don't have the time to be the only / primary author, but I'd be more
than happy to help co-author (if that would be useful), contribute,
review, fold, spindle or mutilate -- whatever would be helpful.

> For the authors of RFC 7710, let us know if you have any concerns.

Speaking for myself: Good -- I'd like it if this became more useful -
my only concern would be the work *not* being done (I'm obviously
perfect in every way, including having the modesty to know my work
could be improved upon :-P )

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Michael Richardson <[email-masked]>
Date: Fri, 02 Mar 2018 21:25:08 -0500

> 3: Since the vast majority of networks don't use CPs, is this an undue

In the case where there *was* a captive portal on a network, and now there is
not, it might be useful to tell clients that life has changed.  The client
might prefer to stay on 3G or pick another network rather than try that
portal.

It might also be meaningful to signal no-captive portal to clients which
have previously connected, but will no longer be challenged (ever? until DHCP
lease timeout?).  For instance, if I whitelist your laptop MAC address in my
home.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 5 Mar 2018 09:46:34 +1100

> Fixing or make RFC7710 more useful ?

Both, I hope.

Thanks for your reply.

> Then the USER could just see that page and decide what to do.

I think that the idea is this:

If the URI is the special one, then the process is done and the
network good to use.
If the URI is special, find the API and check status.  If the portal
says OK, then the network is good to use.
If the API returns captive, open the login page in a browser.

We don't have any more automation than this, but you will observe that
there isn't any probing.  The network can make a clear statement
quickly an unambiguously about access.  If the situation is more
complex (as we have seen that it often is, then it can use the login
page to convey that additional information).

---

From: Martin Thomson <[email-masked]>
Date: Mon, 5 Mar 2018 09:55:23 +1100

> clarity on what exactly would be authenticated.

We have good tools for that now.  In practice, the only relevant
network connectivity needed to validate the cert is the revocation
information.  The current idea is that mandating OCSP stapling is
enough.

Of the other things that are included, AIA is the only one that I know
is used in practice, but that can be forbidden here.  The only reason
to do AIA is to avoid including intermediate certificates in the
handshake, and this is a clear case where doing that is not helpful.
Practically speaking, not all clients do AIA, so it's not an
interoperable choice anyway.

> provide some background on how we ended up here. :-P

That's not substantially different to https://example.com/.  You end
up trusting that your DHCP/RA wasn't intercepted.  Look at it this
way: whatever you get from DHCP/RA is clearly from someone who
controls the network.  If the person who controls the network isn't
the one paying for it, then that's a problem for the person paying for
the network; it doesn't change what the device connecting to the
network thinks.  HTTPS is better in that the target of the URI might
not be on the local network, and so at least you have confidentiality
once packets leave the network.

> review, fold, spindle or mutilate -- whatever would be helpful.

We might hold you to that :)

---

From: Warren Kumari <[email-masked]>
Date: Sun, 4 Mar 2018 20:32:41 -0500

> information.  The current idea is that mandating OCSP stapling is

Okey dokey!

> network thinks.

Yup, 100% agree -- I believe that hte argument wasn't a technical
objection, but rather a human factors / "If we let people think that
it is OK to trust a TLS cert (note the above was HTTP) without having
in mind some identity to tie it to, they will start believing that
this is OK for their bank and similar - cats and dogs will lie down
together, rains of blood, etc."

>  HTTPS is better in that the target of the URI might

Yup. And even if it *is* on the local network, there is a good chance
that this is an unencrypted WiFi network, and so you and all your
fellow coffee drinkers can happy watch the packets go by.

> We might hold you to that :)

Doh! Sure..

W