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
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
----
_______________________________________________
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals
