|
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]>
Date: Sunday, November 1, 2015 at 7:42 AM To: John Mann <[email protected]> Cc: Ben Campbell <[email protected]>, "[email protected]" <[email protected]>, Hirotaka Nakajima <[email protected]>, "[email protected]" <[email protected]>, The IESG <[email protected]>, Barry Leiba <[email protected]>, Warren Kumari <[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]> wrote:
|