Created
October 15, 2015 14:54
-
-
Save wkumari/3754605d53fc050591d1 to your computer and use it in GitHub Desktop.
CAPPORT Charter
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment