Subject: [Captive-portals] Starting to discuss Captive Portals

From: Mark Nottingham <[email-masked]>
Date: Mon, 30 Mar 2015 13:31:28 +1100

Hi everybody,

Thanks to those that came to the Bar BoF in Dallas. Feel free to introduce yourselves here.

I think the strongest outcome there was the interest in the draft for a new DHCP option:
  http://tools.ietf.org/html/draft-wkumari-dhc-capport
IIRC Joel said he was considering sponsoring this document; it would be great to get feedback from OS vendors if they haven't seen it yet.

Hotspot 2.0 <https://en.wikipedia.org/wiki/Hotspot_(Wi-Fi)#Hotspot_2.0> has been brought up by a few people as well. AFAICT, it's focused on "roaming" use cases — e.g., allowing mobile carriers to offer wifi services seamlessly. That's interesting, but AIUI not applicable to *many* use cases where captive portals are used.

Thoughts? 

The wiki we've been using to keep state is here:
  https://github.com/httpwg/wiki/wiki/Captive-Portals
Feel free to edit, and if it gets unwieldily, we can consider moving it out of that space.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 29 Mar 2015 21:42:17 -0700

So, here's a few thoughts:

I suggest to add a requirements section. The reasons why other methods 
suck (Sec. 2) would be a good start, but I suspect there will be 
additional requirements once a bigger audience looks at this.

I suggest to add an example scenario, such as: Jean goes into a coffee 
shop. She signals her agreement to the usage terms and fires up her VPN. 
After an hour, the session expires, and she needs to click "agree" again.

When we add such a scenario, we will most likely recognize that the DHCP 
option is not sufficient for what we need, even for a basic CP. The 
document currently even does not define how applications (the browser, 
other browsers, a mail client, VPN client etc.) can detect that the CP 
is now "open", let alone reliably detect when it has "closed" again. We 
should not rely on the legacy detection methods for this, or we will 
never get rid of them.

Thanks,
	Yaron

On 03/29/2015 07:31 PM, Mark Nottingham wrote:
> _______________________________________________
> Captive-portals mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/captive-portals
>

---

From: Patrick McManus <[email-masked]>
Date: Mon, 30 Mar 2015 08:41:15 -0400

I really appreciate the draft.

There is one thing I really like about the draft, as it operates at a dhcp
level the first hint I'm in a CP happens strictly before any connections
are formed.. that should help keep things orderly without imposing delays
on non-CP scenarios. Unfortunately, because it doesn't help with CP state
(just CP enabled network or not) it does add delay for determining state
with some, potentially slow, internet server for hosts behind CP that are
already whitelisted. For instance, every time I open my laptop in a hotel
for 24 hours after signing the T&C.

I also agree with Yaron's thoughts. I think the document acknowledges a few
problems that it needs to actually deal with to make this practical

* Capture status
* expected TTL to facilitate orderly renewals - surprise renewals are a
real pain point.
* Some kind of authenticable token, separable from the DNS in a https:// CP
url, that clients might whitelist or prioritize (perhaps from history)
* how https:// uris deal with revocation (i.e mandate in-band, or mandate
whitelisting of revocation check, etc..)

On Mon, Mar 30, 2015 at 12:42 AM, Yaron Sheffer <[email-masked]>
wrote:

> suck (Sec. 2) would be a good start, but I suspect there will be additional
> requirements once a bigger audience looks at this.
>
> other browsers, a mail client, VPN client etc.) can detect that the CP is
> now "open", let alone reliably detect when it has "closed" again. We should
> not rely on the legacy detection methods for this, or we will never get rid
> of them.
>
> Thanks,
>         Yaron
>
>
>> IIRC Joel said he was considering sponsoring this document; it would be
>> great to get feedback from OS vendors if they haven't seen it yet.
>>
>> Hotspot 2.0 <https://en.wikipedia.org/wiki/Hotspot_(Wi-Fi)#Hotspot_2.0>
>> has been brought up by a few people as well. AFAICT, it's focused on
>> "roaming" use cases — e.g., allowing mobile carriers to offer wifi services
>> seamlessly. That's interesting, but AIUI not applicable to *many* use cases
>> where captive portals are used.
>>
>> Thoughts?
>>

---

From: Warren Kumari <[email-masked]>
Date: Mon, 30 Mar 2015 14:07:17 -0500

On Mon, Mar 30, 2015 at 7:41 AM, Patrick McManus <[email-masked]> wrote:
> level the first hint I'm in a CP happens strictly before any connections are
> formed.. that should help keep things orderly without imposing delays on
> non-CP scenarios. Unfortunately, because it doesn't help with CP state (just
> CP enabled network or not) it does add delay for determining state with
> some, potentially slow, internet server for hosts behind CP that are already
> whitelisted. For instance, every time I open my laptop in a hotel for 24
> hours after signing the T&C.
>

Fair. I'm (always) happy to accept suggestions on how to address
these... and, of course, even happier to get text :-)

> * Capture status

How about something like requiring that the "Congratulations, you are
now connected to the Internet" page contains a magic string (e.g:
"CP_SATISFIED_JABBERWOCKY" or "The Magic Words are Squeamish
Ossifrage") ? This allows the client to know when it has satisfied the
Captive Portal.

> * expected TTL to facilitate orderly renewals - surprise renewals are a real
> pain point.

How about simply adding a TTL field to the DHCP / RA that lists the
TTL in seconds (or minutes) of how often the client should come back?

One potential issue is that many captive portals give you different
options -- 1 hour for $9.99, 24 hours for $19.95. We could define
another protocol that the client could use to interrogate the CP (in
which case I'd think we could punt this to the grand unified theory
document), or perhaps the "Congrats" page could also include the time
purchased. Or, we could define a well known endpoint on the same URI
that speaks something REST like.

Yes, I know not everything is the web (thank gods!) -- but, let's face
it, for most of the current captive portal scenarios there is an
expectation that users have a browser...

> url, that clients might whitelist or prioritize (perhaps from history)

Huzzahwhat? I'm sorry, but I have no idea what this means... The
client gets some sort of authentication cookie that it can present
back to the CP in the future to prove that it has already
authenticated? Something else? Sorry, not a clue....

> whitelisting of revocation check, etc..)

Oooh. This could get really tricky -- at the moment browsers already
have all sorts of interesting strategies to do, or not do, revocation
checking. This gets even weirder in a world where you are behind a
captive portal.

This has bitten a number of people a number of times. I'm managed to
purge much of this from my brain, but back in ~2011 Apple released
(IIRC) 10.7. This did the "obviously" right thing of doing OSCP
checking and refusing to continue until it got a response --
unfortunately this simply doesn't work from behind most captive
portals.
Actually, many browsers simply don't do revocation checks in the way
the people expect them to -- the classic understanding is that
"browser gets a certificate. It does an OSCP check and / or checks all
of the CRLs to see if the cert is revoked. If it is NOT revoked, it
continues". In the real world, things are, um, messier.
See for example: https://www.imperialviolet.org/2014/04/19/revchecking.html

Opening the revocation can of worms^w spiders is, IMO, a dangerous
idea, and puts me in mind of:
https://www.youtube.com/watch?v=2RyTp-rC2VQ

One thing that I'd like to try and keep is the simplicity -- I'd much
rather have a document that "mostly works, most of the time" completed
in less than a year in favor of an all singing, all dancing, fully
complete solution that solves everyone's problems....but never gets
finished.

Anyway, we've been working on this document since Jan 2014, and most
of the problem has been getting reviews -- I'm really glad that a: the
general CP issue is now being looked at and b: this document is
getting some (much needed) review.

Thanks, W

>> option is not sufficient for what we need, even for a basic CP. The document
>> currently even does not define how applications (the browser, other
>> browsers, a mail client, VPN client etc.) can detect that the CP is now
>> "open", let alone reliably detect when it has "closed" again. We should not
>> rely on the legacy detection methods for this, or we will never get rid of
>> them.
>>
>> Thanks,
>>         Yaron
>>
>>

-- 
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: Yoav Nir <[email-masked]>
Date: Mon, 30 Mar 2015 22:35:48 +0300

> On Mar 30, 2015, at 10:07 PM, Warren Kumari <[email-masked]> wrote:
> 

Not sure the portals want your client to know. It took me a while, but I finally figured out why Apple’s scheme was not working in my hotel. When a Mac goes on a new network, it sends a request for one of several pre-defined URLs. They all return the simple string “success”. If they don’t get that, Mac OS pops up a window and shows the user whatever it got instead.

My hotel would let those requests through so that the system got “success”. After that nothing worked until I browsed to some HTTP site and got the captive portal. So I filled in the super secret password that I got with my room key, and got to a web page about all the great stuff at my hotel. So why did my hotel do this? It’s because they wanted me to see that page. With Apple’s scheme, the moment the system detects that I’m on the real Internet, it makes the special window go away so that I can get some work done. Your CP_SATISTISFIED_JABBERWOCKY would allow the OS to remove the special window, and then I don’t get to see what’s on that page. 

I’m not saying that it’s a bad thing to specify, but we should realize that captive portals, much like websites and OS vendors want to control your experience.

Yoav

---

From: Martin Thomson <[email-masked]>
Date: Mon, 30 Mar 2015 14:36:03 -0500

Is there any sense in moving to .well-known for this?  That would
allow for a status check resource, which would avoid some of the
jankiness of other options.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 30 Mar 2015 14:38:08 -0500

On 30 March 2015 at 14:35, Yoav Nir <[email-masked]> wrote:
> So why did my hotel do this? It’s because they wanted me to see that page.

Yes, this is the real problem here.  It's eyeball-seeking behaviour.
So why not build in an I-need-eyeballs option?

---

From: 🔓Dan Wing <[email-masked]>
Date: Mon, 30 Mar 2015 13:06:11 -0700

On 30-Mar-2015 12:35 PM, Yoav Nir <[email-masked]> wrote:
> My hotel would let those requests through so that the system got “success”.

For example of such configuration, see http://blog.tanaza.com/blog/bid/318805/iOS-7-and-captive-portal-a-guide-to-captive-portal-requirements

> After that nothing worked until I browsed to some HTTP site and got the captive portal. So I filled in the super secret password that I got with my room key, and got to a web page about all the great stuff at my hotel. So why did my hotel do this? It’s because they wanted me to see that page.

The page would be displayed with the OS's restricted browser, too, and you could interact with the page.  Also likely they wanted you to use a full browser (JavaScript, cookies, perhaps also password autofill), rather than the restricted browser the OS likes to use.

-d

> With Apple’s scheme, the moment the system detects that I’m on the real Internet, it makes the special window go away so that I can get some work done. Your CP_SATISTISFIED_JABBERWOCKY would allow the OS to remove the special window, and then I don’t get to see what’s on that page. 
>

---

From: Warren Kumari <[email-masked]>
Date: Mon, 30 Mar 2015 16:14:10 -0400

> So why not build in an I-need-eyeballs option?

I suspect that we are going to be spending a significant amount of our
time with the tension between making the user's life better, and also
trying to maximize the CP operator's desires.

The CP vendor *could* satisfy their desire for eyeballs (puts me in
mind of zombies -- "Braaaaaiiiins... Eyeballls......") by having you
sign in, and then presenting a "Thank you for using our
super-awsome-internets service" (and whatever other ads they desire)
and including a <META http-equiv="refresh"
content="20;URL=http://192.0.2.1/congrats.html">. This would get them
20 seconds of luckless^w happy users looking at their ads. Another
option would be "CP_SATISTISFIED_JABBERWOCKY; PERSISTANT" which would
instruct the host to keep the "Congrats" page around (sure, the host
might just ignore this, but, well, at some point we are going to have
to assume that the CP vendors and hosts are not completely trying to
make the user a sad puppy...)

Ugh.

Some of this discussion gets a little funny because we don't have good
terminology for taking about captive portal techniques. I really suck
at definitions and terminology, so someone else should write this, but
for now I've been thinking of things like this:

Interception - any of the things that CPs do to get you to visit them.
These include:
DNS interception - handing out fake answers to DNS lookups (fake is
meant to mean "different to what the owner of the domain would have
given", and is not intended to be pejorative)
Passive DNS interception - doing the above by handing out answers when
queried directly, for example by having the CP handed out (via DHCP)
as the DNS server.
Active DNS interception - watching DNS requests as they pass though
the CP device and pretending to be the configured DNS server.
<similar terms for HTTP interception, IP hijacking, etc>

"Splash pages" - generic term for all of the pages that the CP
generates and presents to the users.
"Welcome page" - the first page that the user sees from the CP.
Usually says something like "Welcome to hotel foo. You can get
Internets for $price". May include a few more "help" pages, AUP, etc.
"Login pages" - the page(s) that accept user input. These may accept
things like credentials or credit card information, and so may need
SSL/TLS.
"Congrats page" - the page that thanks you for your purchase, and says
that you are now connected to the Internet.
"Status page" - a page that some CPs provide that tells you how much
time you have left on your block of Internet (they usually ask to be
left open). Some of these are simply a javascript thing that
decrements the time, some do a periodic callback to check status, some
actually keep your block / lease alive by periodically poking the CP.
"Site page" - a page that the CP redirects to after the "congrats"
page. After you pay and the CP has told you are on the Internet some
CPs redirect you to a "site information page". This has "useful"
information about the hotel / airport / location where you are
(including stuff like ads for the hotel restaurant, etc.)
"Banner insertion" - (the Fairmont hotel was doing this, but many
attendees probably didn't see if because we'd already taken over the
hotel network and replaced it with the IETF one.) Basically the
captive-portal intercepts HTTP requests and injects an iframe which
presents a banner at the top of the page with a logo and the time
remaining.

"Continue URL" - the URL that the user originally tried to access.
When the CP has been satisfied, it may (should?!) redirect the user to
where they were originally trying to go...

Anyway, I *did* warn you that I suck at terminology -- but, we can use
things like this until we have something better.

W

---

From: Martin Thomson <[email-masked]>
Date: Mon, 30 Mar 2015 16:04:22 -0500

> trying to maximize the CP operator's desires.

Obviously, because the technical concerns aren't what is hard here.

I was talking about this in the context of having some sort of status
resource, which could expire, be refreshed and somehow indicate that
login was again necessary.  That creates the eyeball-seeking behaviour
if user agents respect the request.  It also creates the right
incentives there: if the network really does need re-authorization,
then it's not really something that can be ignored by a UA.

On the other end of things, all you need is a signal from the portal
that the internet access is OK.  A status resource can provide that
indication.  If you request it after every navigation, it's chatty,
but you are likely to get the right result.

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 30 Mar 2015 20:26:16 -0700

> Obviously, because the technical concerns aren't what is hard here.
We should specify behavior of both the CP and the client. Specifically, 
the client MUST display the CP's web page. And hope that most people 
obey the rules, otherwise we will get into another race between OS 
vendors and CP vendors.

And this is my fantasy solution:

/.well-known/captive/status - returns a basic status (CP open/closed), 
and optionally, an expiration time for this information, i.e. when you 
need to poll the status again.

/.well-known/captive/refresh - returns null if no user action is needed 
(rare), or a URL the browser needs to display for the user to beg/pay 
for more time.

The browser could detect these well-known URLs in order to notify the 
rest of the system, or we could wrap them in some fancy JavaScript.

We should still use DHCP to return the address of the resource, so that 
the CP does not need to proxy all IP traffic (it can just drop it, hooray).

Thanks,
	Yaron