Subject: [Captive-portals] Feedback requested: Charter text.

From: Warren Kumari <[email-masked]>
Date: Tue, 23 Jun 2015 14:26:13 -0400

Hi all,

We have a BoF scheduled for the IETF in Prague.

We would like to get a discussion going on some *strawman* charter text.

-----

Captive Portals are used to restrict access to a network until users
have purchased access, or accepted Acceptable Use Polices (AUP).
They accomplish this by intercepting connections from unauthenticated
clients, redirecting them to an authentication server, and then
granting access (if satisfied). By developing a standard set of
Captive Portal interactions (including simple ways for clients to
discover and interact with CPs), we will significantly improve the CP
user experience, increase security, and simply the CP interceptions.
This will increase the user completion rate, increase the CP
interception reliability, and decrease the implementation complexity
and cost.

Many of the interception techniques are very similar to
man-in-the-middle attacks, and, as clients become more secure, are
increasingly ineffective, leading to a poor user experience. Many of
the captive portals require a web browser to interact with the
authentication system, and may require that the user disconnects any
VPNs, browses to a non-HTTPs site, or similar. In addition, there is
no standard way to discover the existence of the captive portal, when
the captive portal has been satisfied, and how much time remains
before the captive portal restricts access again.

The Captive Portal (CAPPORT) Working Group will address these (and
related issues) by defining a standard mechanism for clients to
interact with Captive Portals, including how to connect to the captive
portal and how to communicate with it to obtain status information
such as remaining access time, purchased bandwith class, etc.

This working group will seek participation and input from browser /
operating system vendors, captive portal developers and operators.
One of the known challenges is that some captive portal operators may
not want to use a standard interaction protocol, preferring to perform
more intrusive interception and interactions. We are hoping that the
benefits to CP standardization outlined here are sufficient to not
only encourage input from CP developers and operators, but also aid in
deployment.

Milestones:
TDB: Initial problem statement / use case document [0]
TBD: Initial terminology document [1]
TBD: Initial portal interaction document (perhaps based upon
http://coova.org/CoovaChilli/JSON ?)
TBD: Extended portal interaction document (for systems without browsers)

[ Each of these milestones is actually Initial draft -> WGLC -> IESG, etc ]

[0]: Primarily to ensure that we are understand what we are trying to
accomplish / working to the same goal. This may or may not become an
RFC...
[1]:  We have already discovered that we have issues here - what's the
webpage after the CP has granted access called? What's the "lease"
time called -- different vendors have different names for things.
Crappy first pass:
http://www.ietf.org/mail-archive/web/captive-portals/current/msg00009.html

----

-- 
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: Yaron Sheffer <[email-masked]>
Date: Fri, 26 Jun 2015 19:57:07 +0300

Hi,

My initial understanding of the group's scope was that it is focused on 
consumer use cases (airport, coffee shop). But then one person on the 
list drew a beautiful diagram of an enterprise use case, where the web 
proxy intercepts your traffic until you log in. And I guess some NAC 
devices could also be in scope. I suggest to add a paragraph with 
initial use cases, so we can discuss them at a high level even before we 
publish a fully formed use case I-D.

Personally I can see the case for a narrow or for a wide scope but I 
think we'd better discuss it early rather then leave it fuzzy.

Thanks,
	Yaron

---

From: Dave Dolson <[email-masked]>
Date: Fri, 26 Jun 2015 18:11:09 +0000

A couple of discussion points, since you asked:

1.
"Captive Portal" is a term that seems to be specifically about getting access to the network.
Could this technology embrace other forms of alerts, such as tornado/tsunami/fire/toxic-spill ?
In other words, the ability of the network to interrupt the user with, 
"I need your eyes on this information, right now"

2.
On an unrelated note, should probably allow devices without operators or screens (IoT devices) to fulfill CP requirements.
Hence, not just about browsers rendering HTML to humans, but any kind of client.

3.
Although the proposed charter doesn't say it, some discussion seems to indicate this should be a link-layer 
problem. I.e., a matter for DHCP and the first-hop router. I'd like to see this posed as an internet-layer 
problem, hence applicable to all forms of internet access, and made enforceable by any forwarding device 
along the path. As a simple example, a device behind a NAT may need to receive a captive-portal alert from
an enforcement point on the other side of the NAT.

I don't know if any of my points warrant changes to the proposed charter. But if the above are to be
specifically excluded, it's probably worth saying so.

-Dave

-----Original Message-----
From: Captive-portals [mailto:[email-masked]] On Behalf Of Warren Kumari
Sent: Tuesday, June 23, 2015 2:26 PM
To: [email-masked]
Subject: [Captive-portals] Feedback requested: Charter text.

Hi all,

-----

Milestones:

----

_______________________________________________
Captive-portals mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/captive-portals

---

From: 🔓Dan Wing <[email-masked]>
Date: Mon, 29 Jun 2015 19:33:17 -0700

> "I need your eyes on this information, right now"

Only if the device can handle such alerts (opt-in, somehow).  I mean, we don't want our own fire alarm system interrupted from its communication because of a tornado 10 miles away, and we don't want our Internet-connected door lock interrupted because of a fire (even a fire within the same building).  And we don't want to relive 1987 for our normal web usage, either; https://en.wikipedia.org/wiki/Max_Headroom_broadcast_signal_intrusion.  That is, such interruptions need to be authorized and authenticated.

tl;dr:  No.

> an enforcement point on the other side of the NAT.

I'm not sure how that would work.  Are you mentioning NAT because of address sharing (NAPT) which makes it difficult/impossible to distinguish separate devices on the public side of a NAPT?

I would not want any device along the path able to inject itself to become a captive portal; imagine the chaos if a core router did that.

-d

---

From: Martin Thomson <[email-masked]>
Date: Mon, 29 Jun 2015 23:10:14 -0700

> We would like to get a discussion going on some *strawman* charter text.

I realize that this might be a little controversial, but I really
don't like the term "captive portal".  I think that a valuable product
of this working group would be a thing that accomplishes the goal that
captive portals set out to achieve, without the MitM.

Currently, this charter bemoans the current status where MitM is the
only real option, but does not set out to create a situation that is
materially different.  I'd like to see it say something more
definitive about this.  (And no, I'm not in denial; I expect that
networks will continue to MitM, but we'll never be rid of the beast
until we have a viable alternative).

---
I understand that the aim is to solicit human input as a prerequisite
of authorizing network access.  A secondary goal is to provide
programmatic access to status information, primarily time remaining,
in support of knowing how to get back to the first part.

Those goals could be (minimally) achieved by discovering two pieces of
information:
 - the time remaining on the network
 - where to direct human eyeballs if a change to this time is desired

There is some additional information that could be interesting later, perhaps:
 - programmatic access to login/logoff functions (useful if time-based
charging is involved)
 - information about network paths that are not gated (though I'm
struggling a little to justify this, it's a common enough feature, we
might like to support it, noting that this is usually discovered via a
portal page, which could be sufficient).

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 30 Jun 2015 16:28:18 +1000

+1. 

Cheers,

> On 30 Jun 2015, at 4:10 pm, Martin Thomson <[email-masked]> wrote:
> 

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

---

From: Patrick McManus <[email-masked]>
Date: Tue, 30 Jun 2015 09:26:26 -0400

On Tue, Jun 30, 2015 at 2:10 AM, Martin Thomson <[email-masked]>
wrote:

> I expect that

yes. this. I don't think there is much evidence to suggest incrementalism
to current MITM is going to be more widely accepted than a new saner system.

---

From: Warren Kumari <[email-masked]>
Date: Tue, 30 Jun 2015 13:40:09 -0400

On Fri, Jun 26, 2015 at 12:57 PM, Yaron Sheffer <[email-masked]> wrote:
> consumer use cases (airport, coffee shop). But then one person on the list
> drew a beautiful diagram of an enterprise use case, where the web proxy
> intercepts your traffic until you log in. And I guess some NAC devices could
> also be in scope. I suggest to add a paragraph with initial use cases, so we
> can discuss them at a high level even before we publish a fully formed use
> case I-D.
>
> Personally I can see the case for a narrow or for a wide scope but I think
> we'd better discuss it early rather then leave it fuzzy.

Thank you, this is an excellent point. I'd personally mainly been
thinking of this in the case that I most commonly run into -- I arrive
at a hotel or airport[0] and am presented with the "Please pay $29.99
for 24h of Internet", but the intercepting web proxy is another
usecase. I kinda think that it is a different type of thingie, and out
of scope for this group, but, well, I'm not sure why, not how to
cleanly separate the two (one is "local", one isn't? one is a web
proxy, one isn't?).

I wanted to let everyone know that we have a BoF scheduled for Prague...

15:50-17:20 Wednesday Afternoon session II
Congress Hall - Captive Portal interaction BoF.

Much of this BoF will be to discuss the scope (discovery? interaction?
both? the above thing), etc.
I propose we add this to the discussion - sound good?

W

---

From: Warren Kumari <[email-masked]>
Date: Tue, 30 Jun 2015 13:51:11 -0400

>> Hence, not just about browsers rendering HTML to humans, but any kind of client.

Ideally we will be able to design and build something that works
without user interaction, and we even have a proposed milestone:
TBD: Extended portal interaction document (for systems without browsers)

Unfortunately there are some competing desires / goals here -- captive
portal operators often have a desire for eyeballs (to advertise how
awesome their hotel / coffee / whatever is), and so don't want a fully
automated / handsfree solution; users / devices without screens simply
want Internets...

This is going to be a constant tension -- we don't want to simply tell
the CP deployers that they cannot provide their splash screen or they
won't deploy, but we do want to make this all as simple for users /
devices as possible...

---

From: Warren Kumari <[email-masked]>
Date: Tue, 30 Jun 2015 14:20:49 -0400

> captive portals set out to achieve, without the MitM.

Yup. +1 <aol>me too</aol>

I'd like to stick with the term "captive portal" for now, simply because:
A: that is the name on the BoF / what people think of this as and
B: the terms still seems to make sense to me -- even if there is no
MitM, users will still be 'captive' (imprisoned or confined) until
they convince the network that they need to get out. The 'portal' bit
I cannot really justify, other than the game
(https://en.wikipedia.org/wiki/Portal_(video_game)), which has someone
who want something (cake and grief counseling) but is being thwarted
by technology :-)

> until we have a viable alternative).

Hmmm... I hadn't intended the charter to be so whiney about the
interception bit.

I wanted the charter text to be longer than just:

----------
The Captive Portal (CAPPORT) Working Group will define
a standard mechanism for clients to
interact with Captive Portals, including how to discover and connect,
and how to communicate with it to obtain status information
such as remaining access time, purchased bandwith class, etc.

-----------

We are (probably) asking for the formation of a WG, and I wanted
charter text that explains a bit more about what the issues are, and
explains more about what we will be doing. Perhaps the above is long
enough? Does it need some more text / background? Any proposed text
gratefully accepted...

>  - where to direct human eyeballs if a change to this time is desired

Yup. I think the fact that there *is* a widget that blocks access
until it is satisfied is also needed. This is very similar, but subtly
different to your first bullet....

>  - programmatic access to login/logoff functions (useful if time-based

Yup. This will also be needed for devices that have no UI.

> portal page, which could be sufficient).

Hmmm. interesting...

W

---

From: Martin Thomson <[email-masked]>
Date: Tue, 30 Jun 2015 13:35:31 -0700

> I wanted the charter text to be longer than just:

A longer charter should not be a goal.  You only have to cover the basic points:

Some networks require some form of interaction from users prior to
authorizing network access.  Prior to granting that authorization,
network access might be limited in some fashion.  Frequently, this
authorization process requires human interaction, frequently to either
arrange for payment or accept some legal terms.

Currently, network providers attempt to reach a human user by
intercepting cleartext HTTP to force a redirect to a web page of their
choice.  This design creates a number of problems, primarily: it can
only work if an endpoint initiates a cleartext HTTP connection, and
the interception looks like a MitM attack.

The human eyes needed to access Internet (hmm, maybe your name is
better) working group will define mechanisms that:
 - allow endpoints to discover that they are in such a limited environment
 - allow endpoints to learn about the parameters of their confinement
 - advertise a location whereby human users can directly engage with
their captor in order to obtain unrestricted access
 - (optionally) advertise a service whereby devices can enable or
disable unrestricted access without human interaction

> Yup. This will also be needed for devices that have no UI.

The problem with this last one is that it is unclear how endpoints and
network come to agree upon the terms under which a request of this
form is authorized.  I've not seen a clear model for that, and I
wouldn't want to have one before addressing the more pressing issues.

---

From: Dave Dolson <[email-masked]>
Date: Tue, 30 Jun 2015 21:50:21 +0000

Hyperbole aside, ‎the techniques in use today can be deployed in any network gear along the path, even theoretically in a core router, and also to present any kind of alert. Yet the internet has not degraded into chaos.

I know that some captive portal enforcement points reside at locations other than ‎WiFi access points. Sometimes the networks aren't even WiFi networks. So failing to provide for those would mean mobile devices would need to continue with proprietary methods and new methods as well.

So I think this group could try to solve the general problem, or just address the "WiFi at hotels and airports" problem.‎ The former is what I'd expect from IETF.

-Dave
‎
  Original Message
From: 🔓Dan Wing
Sent: Monday, June 29, 2015 10:33 PM
To: Dave Dolson
Cc: Warren Kumari; [email-masked]
Subject: Re: [Captive-portals] Feedback requested: Charter text.

tl;dr:  No.

-d

---

From: 🔓Dan Wing <[email-masked]>
Date: Tue, 30 Jun 2015 15:55:31 -0700

> So I think this group could try to solve the general problem, or just address the "WiFi at hotels and airports" problem.‎ The former is what I'd expect from IETF.

Joining a network (the captive portal problem) is different from injecting content hours or days after an endpoint has joined a network.

-d

---

From: Yoav Nir <[email-masked]>
Date: Wed, 1 Jul 2015 09:24:44 +0300

> On Jul 1, 2015, at 1:55 AM, 🔓Dan Wing <[email-masked]> wrote:
> 
> 

I agree and I think the latter should be out of scope. 

But we may need a loose definition of “joining a network”. Many airports allow you to join the network and browse some internal sites (departures, arrivals, airport map, stores in the airport), but you get the captive portal as soon as you try to browse to something else.

Yoav