Re: [Captive-portals] Arguments against (any) Capport "API"

[David Bird <[e-mail]>]

A few more key benefits of the ICMP approach :

- Capport detection is made easier for the client, even when RFC 7710 (or
any API) is implemented (as long as the NAS is Capport compliant).

- "Signaling" can be done by different components (NAS, iptables,
rate-limiter, PCEF, etc), without (necessarily) needing to coordinate with
a central service.

- In defining the RFC in how a NAS should handle blocking traffic for
Capport compliant devices, we are also defining how the NAS should handle
Legacy devices - which is, there is no difference - they both get ICMP Dest
Unreach w/Capport extension) - which is helpful.


On Wed, Apr 5, 2017 at 8:15 AM, Christian Saunders <
[e-mail]> wrote:

> You are describing Hotspot 2.0.
>
> 802.1x technology already exists today, but there are reasons for it not
> taking off in public access:
>
>
> Really there are two problems that need addressing when accessing Wi-Fi:
>
> 1. Distributing 802.1x credentials - which Hotspot 2.0 makes headway
> towards accomplishing.
>
> 2. Network access - particularly the user experience which is what the
> Captive Portals exist to resolve.
>
> I find it conceptually more elegant to consider the connectivity and
> access layers separately.
>
> If we can address the access/experience problem we may be able to inform
> Hotspot 2.0 r3+.
>
> Also, the access/experience/portal issue may be more widely applicable
> than just Wi-Fi connectivity.
>
> Cheers!
>
> Christian
>
>
> On 17-04-05 07:04 AM, David Bird wrote:
>
> On Tue, Apr 4, 2017 at 9:19 PM, Mikael Abrahamsson <[e-mail]>
> wrote:
>
>> On Tue, 4 Apr 2017, David Bird wrote:
>>
>> For some locations, they may simply WANT to annoy you! (While also
>>> collecting per session fees from Boingo or iPass for the privileged of
>>> skipping that annoying portal.) More than likely, however, sites like the
>>> one you mentioned are just themselves concerned about liability and want
>>> that minimal amount of disclaimer...
>>>
>>
>> Let me rephrase the question:
>>
>> Is there today a mechanism widely deployed in mobile devices for free use
>> by (for instance) a hotel that just wants to make sure that someone enters
>> their credentials (to stop passers-by to use it) and wants to view and
>> accept the TOS *once*, and then subsequenty it's ok if you just enter same
>> credentials each time you connect and it's fine if the user never sees the
>> captive portal for subsequent attempts.
>>
>>
> Yes, mechanisms exists today. It is not uncommon, for instance, for the
> portal to record your acceptance along with your MAC address and then do
> "MAC authentication" for your device for some time thereafter.
>
> The Hotspot portal could also do a lot of things in the website itself to
> help with ease of use... (provided you are not using a crippled browser
> because of a naive captive portal detector) like remembering your state
> from cookies, etc, and logging you in without you noticing.
>
>
>
>> Is this available? In that case, what mechanism is that and where can I
>> read up on it?
>>
>> If it's not available, then that's one thing I think we should do here.
>>
>>
> The mechanisms exists... and, this is very much dependent on the access
> policy of the venue -- not all venues will want the same thing.
>
>
>> What about an enterprise SSID that allows anyone to connect to it, but
>> the only thing you get is a captive portal. After you've accepted terms of
>> service and entered username/password, this is now somehow provisioned into
>> your device as 802.1x credentials and you then disconnect and reconnect
>> with these new credentials, which gives you access as long as these
>> credentials are valid?
>>
>>
> You are describing Hotspot 2.0.
>
> 802.1x technology already exists today, but there are reasons for it not
> taking off in public access:
>
> - It isn't easy to use (without Hotspot 2.0) and doesn't necessarily mean
> you don't have a portal anymore. For instance, what does the network do
> when you run out of time? Just dump you off the secure wireless or give you
> a portal on the secure wireless?
>
> - Users don't care (and prefer the ease of use)
>
> - I'd argue it gives a FALSE sense of security to users, who are, after
> all, using public access with no real trust relationship with the venue or
> the network provider. Sure, wireless security moves the bar (a little bit)
> in terms of passive attacks, but doesn't protect the user from active
> attacks or in-line snooping off the wire. Having users see the SECURE WiFi
> indication on public access networks (like they see at home) is misleading.
> The user is better off with end-to-end security. As QUIC deploys, perhaps
> wireless security in public access will be less of an issue.
>
> [Note: 802.1X can be _implemented_ in ways that still leave the user
> vulnerable to active attacks. For instance, with EAP-TTLS, if you don't pin
> the profile to a server certificate, your device can be fooled into
> revealing your credentials to a rogue AP.]
>
>
>
>>
>> --
>> Mikael Abrahamsson    email: [e-mail]
>>
>
>
>
> _______________________________________________
> Captive-portals mailing [e-mail]://www.ietf.org/mailman/listinfo/captive-portals
>
>
>