WG Review: Captive Portal Interaction (capport)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



A new IETF working group has been proposed in the Applications and
Real-Time Area. The IESG has not made any determination yet. The
following draft charter was submitted, and is provided for informational
purposes only. Please send your comments to the IESG mailing list (iesg
at ietf.org) by 2015-10-26.

Captive Portal Interaction (capport)
------------------------------------------------
Current Status: Proposed WG

Chairs:
  Martin Thomson <martin.thomson@gmail.com>
  Warren Kumari <warren@kumari.net>

Assigned Area Director:
  Barry Leiba <barryleiba@computer.org>

Mailing list
  Address: captive-portals@ietf.org
  To Subscribe: https://www.ietf.org/mailman/listinfo/captive-portals
  Archive:
http://www.ietf.org/mail-archive/web/captive-portals/current/maillist.html

Charter:

Some networks require interaction from users prior to authorizing
network access.  Before that authorization is granted, network access
might be limited in some fashion.  Frequently, this authorization
process requires human interaction, either to arrange for payment or to
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), and these interceptions are
indistinguishable from man-in-the-middle attacks. As endpoints become
inherently more secure, existing interception techniques will become
less effective or will fail entirely. This will result in a poor user
experience as well as a lower rate of success for the Captive Portal
operator.

The CAPPORT Working Group will define secure mechanisms and protocols to
- allow endpoints to discover that they are in this sort of 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
  and remaining access time, and
- optionally, advertise a service whereby devices can enable or disable
  unrestricted access without human interaction.

The working group may produce working documents to define taxonomy and
to survey existing portals and solutions. These might or might not be
published as RFCs, and might or might not be combined in some way.

Out of scope are "roaming" or federated types of solutions (Passpoint,
eduroam, iPass, Boingo), which use mechanisms such as 802.1X or a client
application to authenticate.  These are not really captive portals, and
have largely been solved in other ways.

Initially, the working group will focus on simplifying captive portal
interactions where a user is present. A secondary goal is  to look at
the problem posed to or by devices that have little or no recourse to
human interaction.

Milestones:
  Jun 2016 - Captive Portal Industry Survey
  Jun 2016 - Captive Portal Taxonomy
  Dec 2016 - Protocol to discover and interact with a Captive Portal





[Index of Archives]     [IETF]     [IETF Discussion]     [Linux Kernel]

  Powered by Linux