[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Captive-portals] Ben Campbell's Yes on charter-ietf-capport-00-01: (with COMMENT)

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:

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,


On 16 October 2015 at 13:04, Barry Leiba <[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.


Captive-portals mailing list
[email protected]

Captive-portals mailing list
[email protected]