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

From: "Nicolas Mailhot" <[email-masked]>
Date: Wed, 1 Jul 2015 10:46:58 +0200

Le Mer 1 juillet 2015 00:55, 🔓Dan Wing a écrit :

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

Not really unless you limit yourself to system with auth that never
expires (which, from a security POW, is heresy)

-- 
Nicolas Mailhot

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 1 Jul 2015 16:13:01 +0300

Warren Kumari writes:
> > 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
> 
> 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....

Yes, and the problem is that this also blocks also non-web traffic,
i.e. your email client in your phone canont get your emails over
imaps, your facebook client do not get notifications etc.

And this is connected to next:

> > There is some additional information that could be interesting
> > later, perhaps: 
> >  - programmatic access to login/logoff functions (useful if time-based
> > charging is involved)
> 
> Yup. This will also be needed for devices that have no UI.

This is not only related to the devices that have no UI, but also to
devices where the UI is not active at the time they want to use the
network (I.e. phone is in the pocket, but getting notification about
new emails or some notifications would be nice).

There is lots of places where you get this login page, which just
lists some terms of usage and policies, and you just click Agree and
then you can get to the network. The problem is that next time you
come to the same lication you need to click it again. Which means
every time I go to the Helsinki Airport, I need to start browser, and
try to access something so I can click "I agree" so I can get my
emails downloading in the background. This is annoying and one of the
original ideas was that there would be a way to tell to the captive
portal that I have already agreed on the terms described on page xyz,
and if they are unchanged, log me in. If not, I can go and ask
question again from user...
-- 
[email-masked]

---

From: Martin Thomson <[email-masked]>
Date: Wed, 1 Jul 2015 10:01:40 -0700

On 1 July 2015 at 06:13, Tero Kivinen <[email-masked]> wrote:
> Which means
> emails downloading in the background.

That may be a legal constraint.  The network they provide isn't
entirely for your convenience.  That said, one potential mechanism is
one where the "portal" establishes a cookie that you can use next time
to automatically log in.  Previous visits being perhaps the only
example where automatic login is actually easy.

---

From: Warren Kumari <[email-masked]>
Date: Wed, 1 Jul 2015 13:25:46 -0400

> example where automatic login is actually easy.

There are also locations the whitelist some clients, based upon MAC
address and the "if you can do 802.1X you get unrestricted access,
otherwise we captive portal you" - this is *sort of* similar to
automatic login, if you squint at it just right (actually it is simply
a bypass of the CP for known clients, but users don't understand
that).  Some Linksys CPE also has a builtin captive portal - they
create 2 wireless SSIDs, one with WPA (or similar) and a guest network
for friends and such -- this is kinda similar to the 802.1X system in
that "authorized" people bypass the CP entirely.

Whatever the case, what we'd like is a way for clients that connect to
a network that is restricted by a captive portal to *know* that they
are behind a CP, how to find it, and how to interact with it.
interacting with it includes discovering status, like remaining access
time, etc.

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: Warren Kumari <[email-masked]>
Date: Wed, 1 Jul 2015 13:45:27 -0400

On Wed, Jul 1, 2015 at 1:01 PM, Martin Thomson <[email-masked]> wrote:
> That may be a legal constraint.

Yup, in a number of jurisdictions the network provider is required to
be able to identify the people connecting for legal reasons. In a
bunch of other cases the network operator has been advised by their
lawyers that they need customers to accept an AUP, promising not to do
anything naughty.

I think that we should rule the *reason* for the captive portal's
existence out of scope (or we're likely to get wrapped around endless
political type fights) and simply acknowledge that there are 3 main
types:
1: Those that require some information / acknowledgement, like an AUP.
2: Those that require payment
3: Those that require you to be an eyeball - an example of this is the
Wifi at Dulles airport (IAD) - the network is provided by AT&T (IIRC)
and you have to watch a fairly long video advert before you get
access. A related thing is requiring you to access Facebook and "Like"
an organization / install an app, etc. -- see
http://www.recaptive.net/features/captiveportal/

These different types may be important for the interaction system --
for example, the 3rd type is less likely (IMO) to allow a fully
hands-free login experience.

In order to make this all actually work, we are going to have to
create an environment where users, OS vendors, captive portal vendors
and captive portal operators can all work together towards improving
the user experience, and not pass judgement on motivations, etc.

> The network they provide isn't

Yup.
E

---

From: Warren Kumari <[email-masked]>
Date: Thu, 9 Jul 2015 10:16:12 -0400

Here is what I currently have.

-------------------------------
Some networks require 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 use a number of interception techniques
to reach a human user (such as intercepting cleartext HTTP to force a
redirect to a web page of their choice), many of which look like a MitM
attack. As endpoints become inherently more secure, existing interception
techniques will become less effective and/or will fail. This results in a poor
user experience as well as a lower rate of success for the Captive Portal
operator.

The CAPPORT Working Group will define mechanisms and protocols to:
 - allow endpoints to discover that they are in such a limited environment
 - allow endpoints to learn about the parameters of their confinement
 - provide a URL to interact with the Captive Portal and satisfy the
 requirements
 - interact with the Captive Portal to obtain information
such as status, remaining access time, etc.
 - (optionally) advertise a service whereby devices can enable or
disable unrestricted access without human interaction

-------------------------------

I think that much of the work / output will be a protocol for users /
clients to better interact with the CP.
I'd like to arrive at my hotel, and have my machine know that I'm
behind a CP and seamlessly present me with a "Welcome to hotel X,
please pay $19.99 for 24h of access" - at the moment this doesn't work
very reliably.
I'd like to purchase 24 hours of access, and then after 23hour 45
minutes have my machine tell me that I'm running low and allow me to
purchase some more.
I'd like to not have iTunes / my MUA present me with 27 different
popups, all telling me that the cert for <foo> doesn't match what was
expected.
I'd like this all to Just Work(tm)

W

On Tue, Jun 30, 2015 at 4:35 PM, Martin Thomson
<[email-masked]> wrote:
> On 30 June 2015 at 11:20, Warren Kumari <[email-masked]> wrote:
>> 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
>
> On this last point:
> 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: Alexandre Fiori <[email-masked]>
Date: Thu, 9 Jul 2015 11:04:30 -0400

+1

Besides hotels, there's a number of cheap pre-paid mobile plans with similar confinement. In those networks, you get the same cert warnings from your apps, MUA, and so on.

> On Jul 9, 2015, at 10:16 AM, Warren Kumari <[email-masked]> wrote:
> 
> _______________________________________________
> Captive-portals mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/captive-portals

---

From: Michael Richardson <[email-masked]>
Date: Thu, 09 Jul 2015 11:12:34 -0400

Warren Kumari <[email-masked]> wrote:
    > attack.

I think this is too weak.
I would say:

    Currently, network providers use a number of interception techniques
    to reach a human user.  Technically, most of the mechanisms are
    Man-in-The-Middle Attacks against DNS or HTTP.  This has the effect
    of redirecting all HTTP traffic to a web page of their choice, even
    for requests which are not viewed by a human.  It often also results
    in permanent DNS cache poisoning.

    As endpoints become inherently more secure specifically through DNSSEC,
    and HTTPS-everywhere, existing interception techniques not only fail to
    reach a human, but usually result in a the user and the device being
    confused: their either give up, or complain loudly that the network is
    broken (which technically, it is).

    In the cases where the technique does reach a human, it often results
    in a security warning about a broken certificate, and the resulting
    technique is therefore training users to ignore those warnings.

===

I find your list of deliverables perfect.
I think that this effort could benefit from some significant outreach by
ISOC (and perhaps the IAOC meeting people could involve their contacts): we
need to reach the hotel managers.

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

---

From: Yoav Nir <[email-masked]>
Date: Thu, 9 Jul 2015 18:46:41 +0300

> On Jul 9, 2015, at 5:16 PM, Warren Kumari <[email-masked]> wrote:

<snip />

> disable unrestricted access without human interaction

This may be covered by the third bullet (sort of...) but I would like the endpoint to be able to authenticate the captive portal (captor? MitM?). This could be done by requiring that the URL be https and that the certificate identify the portal.  For example, I’m typing this while riding a train on my way home. If the captive portal here had a CN or alternate name such as “www.rail.co.il” or “captive-portal.rail.co.il” that would be fine. If it said “CN=acme-initial-certificate,OU=replace-before-deploying,O=do-not-use-in-production” I would be more worried about using it.

I think publicly trusted certificates are now cheap enough that we can require them in (new) captive portals. This is especially important in places like some airports where the portals ask for your credit card number.

I realize this has its limitations. If I go to Frankfurt airport and the certificate says “CN=captive.frankfurtflughafen.de” I don’t know if this is the real domain of the airport or a convincing domain name somebody registered in order to obtain the certificate. But methods to get the right identity can be layered on top of authentication.

Yoav

---

From: Martin Thomson <[email-masked]>
Date: Thu, 9 Jul 2015 10:53:03 -0700

> Here is what I currently have.

LGTM.

On 9 July 2015 at 08:46, Yoav Nir <[email-masked]> wrote:
> I would like the endpoint to be able to authenticate the captive portal (captor? MitM?).

This is a fine secondary requirement; I don't know that it needs to be
part of the charter though.

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Fri, 10 Jul 2015 11:57:04 +0200

Le Jeu 9 juillet 2015 17:46, Yoav Nir a écrit :

> This may be covered by the third bullet (sort of...) but I would like the
> endpoint to be able to authenticate the captive portal (captor? MitM?).

not only authenticate, but protect the client-portal link. Since some
portals require sensitive information (credit card, credentials) and there
will be zero browser buy-in otherwise anyway

Regards,

-- 
Nicolas Mailhot

---

From: Wendy Seltzer <[email-masked]>
Date: Fri, 10 Jul 2015 18:15:34 -0400

On 07/09/2015 10:16 AM, Warren Kumari wrote:
...
> I'd like this all to Just Work(tm)

I'd like to be able to use a minimal UA designed and sandboxed for the
sole purpose of responding to CapPorts, if I don't want to entrust my
usual browser with anything except a (secure|tunnelled|VPNd|Tor)
connection.

[See
https://blog.torproject.org/blog/preliminary-analysis-hacking-teams-slides
]

--Wendy

-- 
Wendy Seltzer -- [email-masked] +1.617.715.4883 (office)
Policy Counsel and Domain Lead, World Wide Web Consortium (W3C)
http://wendy.seltzer.org/        +1.617.863.0613 (mobile)

---

From: Warren Kumari <[email-masked]>
Date: Sun, 12 Jul 2015 11:10:13 -0400

On Thursday, July 9, 2015, Michael Richardson <[email-masked]> wrote:

>
> Warren Kumari <[email-masked] <javascript:;>> wrote:

I originally had something much stronger (with a litany of issues that CPs
cause) , but toned it down after it was pointed out that this doesn't make
it an environment where we will get cooperation from CP vendors and
operators.

I'm trying to keep it "friendly"...

> I find your list of deliverables perfect.

Thank you.

> need to reach the hotel managers.

Yup. We need input from captive portal vendors, captive portal operators,
operating systems, applications, security folk, etc. Jim Martin and myself
are part of the IETF NOC team and so we know some of the hotel CP folk, but
we will also chat with the IAOC folk. But, yes, this is going to need lots
of outreach -- I really like the ISOC angle...

W

>
> --
> Michael Richardson <[email-masked] <javascript:;>>, Sandelman
> Software Works

-- 
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: Mon, 13 Jul 2015 13:49:04 -0400

Warren Kumari <[email-masked]> wrote:
    > we will also chat with the IAOC folk. But, yes, this is going to need lots of
    > outreach -- I really like the ISOC angle...

I find that many captive portals that screw with DNS don't stop after you
authenticate, and so will continue to break DNSSEC even afterwards.  The Bell
Canada DataValet CP which is deployed at many hotels and conference centers
is like this, and it also failed (I suspect: core dumped) when the reply had
AAAA records.
So this work fits into ISOC's Deploy 360 on IPv6 and DNSSEC for this reason.

I know that I previously said that the milestones were good, but I realized
that I was wrongish:

We need to publish a problem statement and security analysis first, (and do
it quickly), and get it out.  At that point, one can actually say, "Hotel XYZ
is not BCPabc compliant", and the developers will have something to actually
beat their marketing people with.  The threat that an operator will kick a
supplier out over a performance specification (that's the NAFTA/CETA and
probably TPP term) can be a real threat.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 13 Jul 2015 13:51:01 -0400

Robbie Honerkamp <[email-masked]> wrote:
    > Some of us are here - I’m at DOCOMO interTouch (CP operator for the hotel
    > industry), and we also own Nomadix, which is a CP gateway hardware vendor.
    > Speaking from the industry standpoint, everyone knows this is a problem
    > (“everyone” = CP operators *and* hoteliers) and would like to have a solution
    > in place yesterday. As HTTPS use grows, the current CP methods will no longer
    > work, and we’re just teaching users to do the Wrong Thing by clicking through
    > certificate validation warnings.

So very thrilled to meet you!!!

Do you think that the hotel IT folks would join this list?

    > So, for what it’s worth, we’re 100% willing and able to help wherever we can
    > to make this successful.

Good.  I also hope that you'll be able to eat some competition by having a
better product.