IETF-93 Proceedings

Introduction  |  Area, Working Goup & BoF Reports  |  Plenaries  |  Training  |  Internet Research Task Force

Captive Portal Interaction (capport) (WG)

Minutes   |   Jabber Logs  |   Mailing List Archives

Additional information is available at


Applications and Real-Time Area Area Director(s):

Assigned Area Director


Meeting Slides:

Blue Sheets:

No Current Internet-Drafts

No Request for Comments

Charter (as of 2015-09-30):

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 often
look like 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/or might 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 stretch-goal / phase 2 work may attempt to solve this problem
for devices that have no human interaction (such as "IoT" devices).