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

[Warren Kumari <warren@kumari.net>]

On Fri, Jun 26, 2015 at 12:57 PM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
> 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.

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

>
> Thanks,
>         Yaron
>
>
> On 06/23/2015 09:26 PM, Warren Kumari wrote:
>>
>> 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