Here is what I currently have. ------------------------------- Some networks require interaction from users prior to authorizing network access. Prior to granting that authorization, network access might be limited in some fashion. Frequently, this authorization process requires human interaction, frequently to either arrange for payment or 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), many of which look like a MitM attack. As endpoints become inherently more secure, existing interception techniques will become less effective and/or will fail. This results in a poor user experience as well as a lower rate of success for the Captive Portal operator. The CAPPORT Working Group will define mechanisms and protocols to: - allow endpoints to discover that they are in such a 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, remaining access time, etc. - (optionally) advertise a service whereby devices can enable or disable unrestricted access without human interaction ------------------------------- I think that much of the work / output will be a protocol for users / clients to better interact with the CP. I'd like to arrive at my hotel, and have my machine know that I'm behind a CP and seamlessly present me with a "Welcome to hotel X, please pay $19.99 for 24h of access" - at the moment this doesn't work very reliably. I'd like to purchase 24 hours of access, and then after 23hour 45 minutes have my machine tell me that I'm running low and allow me to purchase some more. I'd like to not have iTunes / my MUA present me with 27 different popups, all telling me that the cert for <foo> doesn't match what was expected. I'd like this all to Just Work(tm) W On Tue, Jun 30, 2015 at 4:35 PM, Martin Thomson <martin.thom...@gmail.com> wrote: > On 30 June 2015 at 11:20, Warren Kumari <war...@kumari.net> wrote: >> I wanted the charter text to be longer than just: > > A longer charter should not be a goal. You only have to cover the basic > points: > > Some networks require some form of interaction from users prior to > authorizing network access. Prior to granting that authorization, > network access might be limited in some fashion. Frequently, this > authorization process requires human interaction, frequently to either > arrange for payment or accept some legal terms. > > Currently, network providers attempt to reach a human user by > intercepting cleartext HTTP to force a redirect to a web page of their > choice. This design creates a number of problems, primarily: it can > only work if an endpoint initiates a cleartext HTTP connection, and > the interception looks like a MitM attack. > > The human eyes needed to access Internet (hmm, maybe your name is > better) working group will define mechanisms that: > - allow endpoints to discover that they are in such a limited environment > - allow endpoints to learn about the parameters of their confinement > - advertise a location whereby human users can directly engage with > their captor in order to obtain unrestricted access > - (optionally) advertise a service whereby devices can enable or > disable unrestricted access without human interaction > > On this last point: >> Yup. This will also be needed for devices that have no UI. > > The problem with this last one is that it is unclear how endpoints and > network come to agree upon the terms under which a request of this > form is authorized. I've not seen a clear model for that, and I > wouldn't want to have one before addressing the more pressing issues. -- 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 _______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
