I disagree with not supporting "on-boarding / provisioning to secure networks" I am unaware of this problem being solved. I think the captive portal is the easiest and seamless way of upgrading a user from open access to a secure channel. I am a strong believer of securing every layer and the open PHY layer for WiFi is a vulnerability. The captive portal clients for Android and Apple are very close to supporting it and I think we could help define some basic behavior of "upgrading" to a secure connection. I believe an open access WiFi captive portal will always be necessary for connecting new users. Once a user authenticates in the limited captive portal browser, it would be helpful to define an ability for a user to upgrade their security by allowing the installing of a profile.
-- Alexander Roscoe Comcast - Wireless Engineer Phone - 215.286.7283 Cell - 215.609.2691 From: David Bird <[email protected]<mailto:[email protected]>> Date: Sunday, November 1, 2015 at 7:42 AM To: John Mann <[email protected]<mailto:[email protected]>> Cc: Ben Campbell <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, Hirotaka Nakajima <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, The IESG <[email protected]<mailto:[email protected]>>, Barry Leiba <[email protected]<mailto:[email protected]>>, Warren Kumari <[email protected]<mailto:[email protected]>> Subject: Re: [Captive-portals] Ben Campbell's Yes on charter-ietf-capport-00-01: (with COMMENT) Sorry for the late comments here, With respect to: 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. - What do others think about excluding 'network selection' in general from the scope? (i.e. 'on-boarding' onto secure wireless, which starts to overlap with HS2.0). - While I agree that roaming and federated solutions are out of scope, it might be too strong to outright exclude HS2.0/Passpoint, iPass, Boingo, and the like. In HS2.0 release 2, for example, an OSU network can have a captive portal (and I think capport work could apply here) - likewise, I think iPass and Boingo (apps) could benefit form the simplifying of captive portal interactions. (Additionally, even if a network uses 802.1x or an application to authenticate, that doesn't necessarily mean it will be and remain captive portal free -- consider the scenario where a user is being required to top-up their account balance to continue using the 802.1x network). Suggested text: Out of scope are "roaming" (federation of credentials), network selection, or the on-boarding/provisioning of clients onto secure (or any alternate) networks. These are not captive portal specific problems and have largely been solved in other ways. On Thu, Oct 15, 2015 at 8:20 PM, John Mann <[email protected]<mailto:[email protected]>> wrote: Hi, On a slight tangent, I would like to mention that most client computers are now capable of using IPv6, with many preferring it because e.g. Facebook reportedly loads 15% faster. Hopefully, sometime, some networks managed by Captive Portals will become dual-stack. Lets not set the standard for all future captive portal networks to be IPv4-only forever. Hopefully, it may even be possible for clients to operate IPv6-only if they choose. Suggested text: insert after "- allow endpoints to learn about the parameters of their confinement," --- - allow endpoints to learn about and interact with the Captive Portal over IPv6, and allow endpoints to access the IPv6 Internet, --- Thanks, John On 16 October 2015 at 13:04, Barry Leiba <[email protected]<mailto:[email protected]>> wrote: > Sorry just a typo correction and maybe too late for the comments but > eduroam should not be eduRoam but eduroam. > > It would be great if this typo could be fixed. And so it is. Thanks for pointing it out. Barry _______________________________________________ Captive-portals mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/captive-portals _______________________________________________ Captive-portals mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/captive-portals
_______________________________________________ Captive-portals mailing list [email protected] https://www.ietf.org/mailman/listinfo/captive-portals
