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

From: David Bird <[email-masked]>
Date: Sun, 1 Nov 2015 03:42:16 -0800

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-masked]> 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-masked]> 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-masked]
>> https://www.ietf.org/mailman/listinfo/captive-portals
>>
>
>
> _______________________________________________
> Captive-portals mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/captive-portals
>
>

---

From: "Roscoe, Alexander" <[email-masked]>
Date: Mon, 2 Nov 2015 00:27:29 +0000

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-masked]<mailto:[email-masked]>>
Date: Sunday, November 1, 2015 at 7:42 AM
To: John Mann <[email-masked]<mailto:[email-masked]>>
Cc: Ben Campbell <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Hirotaka Nakajima <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, The IESG <[email-masked]<mailto:[email-masked]>>, Barry Leiba <[email-masked]<mailto:[email-masked]>>, Warren Kumari <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Captive-portals] Ben Campbell's Yes on charter-ietf-capport-00-01: (with COMMENT)

With respect to:

- 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-masked]<mailto:[email-masked]>> 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

And so it is.

Barry

_______________________________________________
Captive-portals mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/captive-portals

_______________________________________________
Captive-portals mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/captive-portals

---

From: David Illsley <[email-masked]>
Date: Wed, 18 Nov 2015 07:49:33 +0000

<snip>

> required to top-up their account balance to continue using the 802.1x

I'm far from an expert, but my reading of the Hotspot 2.0 OSU buts suggest
that it 'fixes' the captive portal problem by giving the client the
sign-up/portal address in the OSU handshake (ANQP). Have I misunderstood
this?

---

From: David Bird <[email-masked]>
Date: Wed, 18 Nov 2015 09:17:42 -0800

> sign-up/portal address in the OSU handshake (ANQP). Have I misunderstood
That is correct... My point is just that HS2 might likely be deployed
alongside a captive portal network also used by legacy devices.. the OSU
network can be the Open SSID w/captive portal network. HS2 clients wouldn't
interact with the captive portal, but it might still be there.
Additionally, I don't think HS2 addresses how OSEN networks should enforce
a walled garden (restricting clients only to OSU resources).

My main point is that I don't necessary think "Passpoint, Boingo, iPass"
need to be mentioned by name as they are. They are more than "federated"
logins and capport solutions _can_ be used by these Apps and deployments.

The bigger point is to exclude the 'on-boarding/provisioning of clients
onto alternative (secure) networks' from the charter explicitly.