Re: [Captive-portals] Remediation url for CAPPORT

[Dan Wing]

To that point, the remediation URL only works if the client and the CP are in 
sync; that is, if the client wondered off to another network for a while (LTE, 
because of whatever reason) and then re-connected to WiFi, is the remediation 
URL supposed to be visited because the wall-clock time expired, or not visited 
because the time-on-network has not yet expired.  The CP may have abandoned 
that client, figuring it went away permanently when it disconnected from WiFi.

-d


> On Jan 13, 2020, at 5:02 PM, Tommy Pauly  
> wrote:
> 
> I have a similar initial reaction to Erik's. Adding another URL that 
> effectively is just another user portal, but meant to be used at certain 
> times, adds a lot of complexity. I'm certainly not ruling out adding such a 
> key as need arises, but I'd hesitate to make it part of the initial set.
> 
> Particularly, if we start seeing the "venue URL" be the main landing page we 
> redirect people to once they're logged it, it kind of makes sense to let the 
> user portal be the status/remediation/payment page.
> 
> Tommy
> 
>> On Jan 13, 2020, at 4:06 PM, Erik Kline > > wrote:
>> 
>> 
>> 
>> On Mon, 13 Jan 2020 at 15:26, Heng Liu 
>> mailto:40google@dmarc.ietf.org>> 
>> wrote:
>> On Sun, Jan 12, 2020 at 2:34 PM Erik Kline > > wrote:
>> Why should this different from the user-portal-url?  It seems to me that 
>> either the user-portal-url would remediation UI elements or it wouldn't.
>> Some CP vendors want to specify a different URL specifically tailored for 
>> remediation of a session. By providing a 3rd URL, we can accommodate this 
>> use case.
>> 
>> If the remediation URL is available but the user (somehow) navigates to the 
>> user-portal-url, what do they see?
>> 
>>  
>> With this 3rd URL, if the bytes/time does expire should the OS try to launch 
>> an interaction the remediation URL and then fallback to the user URL if it 
>> failed to load?  In which case, why not just leave all interaction with the 
>> user-portal-url?
>> if a remediation URL is present, and if it fails to load for whatever 
>> reason, no need to fallback to user portal URL: CP vendor should make sure 
>> the remediation URL is working properly (this is similar to user-portal url 
>> should work properly, if not, there is no other way for user to clear a CP)
>> 
>> I guess I'm just trying to be mindful of one person's flexibility is another 
>> person's complexity.  I think this just doubles the number of URLs that the 
>> CP vendor needs to make sure function correctly.
>> 
>> If the vendor doesn't implement a means to extend your session without 
>> completely shutting everything down and forcing to the user to restart the 
>> interaction flow anew, I could see that an OS would not want to bother the 
>> user with an interaction where they couldn't actually do anything useful.  
>> But that might suggest a boolean capability, rather than a new URL 
>> (remediation-supported={true|false})?
>> A boolean field could also be a positive signal to notify UE that 
>> remediation is possible, but this would prevent CP vendors from using 
>> different URLs for remediation.
>> 
>> (As mentioned in the initial thread, this URL approach is also taken by the 
>> Passpoint release 2.0 spec to signal remediation process.)
>> 
>> regards,
>> Heng
>> ___
>> Captive-portals mailing list
>> Captive-portals@ietf.org 
>> https://www.ietf.org/mailman/listinfo/captive-portals 
>> 
>> ___
>> Captive-portals mailing list
>> Captive-portals@ietf.org 
>> https://www.ietf.org/mailman/listinfo/captive-portals 
>> 
> ___
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] Any other existing detection methods?

[Dan Wing]

Text in the PR is unclear if it intends to be normative ("This check should not 
be secured with TLS") or is discussing why TLS isn't used.  In my view, the 
hostname mismatch is a strong indicator the captive portal is intercepting the 
connection; in fact, that's exactly what my mail user agent complains about 
when my OS fails to detect the captive portal.  This failure occurs because 
captive portals purposefully return the "expected text", in order to fool the 
OS into displaying a WiFi "connected" indicator (the "pie") in the hopes the 
user will launch a non-restricted browser and view an un-encrypted HTTP page.  
Which is a faint hope in 2019 with nearly every page being HTTPS and with 
non-browser applications that may launch first (e.g., mail user agent, 
Facebook, Instagram, WhatsApp, etc.).

-d



> On Apr 1, 2019, at 8:52 AM, Thomas Peterson  wrote:
> 
> A recent pull request[0] for the architecture document contains a new 
> appendix describing known methods devices may use to detect a captive portal. 
> Two of the ways I have found are DNS and HTTP based.
> 
> Are the any other means that clients use to detect captive portal presence 
> besides what I have described? Wikipedia lists ICMP redirect[1] as a means, 
> but I have been unable to find documentation from a vendor to support this.
> 
> 
> Regards
> 
> 
> 0: https://github.com/capport-wg/architecture/pull/26
> 
> 1: https://en.wikipedia.org/wiki/Captive_portal#ICMP_redirect
> 
> ___
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] Feedback requested: Charter text.

[🔓Dan Wing]

On 30-Jun-2015 02:50 pm, Dave Dolson  wrote:
> 
> Hyperbole aside, ‎the techniques in use today can be deployed in any network 
> gear along the path, even theoretically in a core router, and also to present 
> any kind of alert. Yet the internet has not degraded into chaos.
> 
> I know that some captive portal enforcement points reside at locations other 
> than ‎WiFi access points. Sometimes the networks aren't even WiFi networks. 
> So failing to provide for those would mean mobile devices would need to 
> continue with proprietary methods and new methods as well.
> 
> So I think this group could try to solve the general problem, or just address 
> the "WiFi at hotels and airports" problem.‎ The former is what I'd expect 
> from IETF.

Joining a network (the captive portal problem) is different from injecting 
content hours or days after an endpoint has joined a network.

-d


> 
> -Dave
> ‎
>  Original Message
> From: 🔓Dan Wing
> Sent: Monday, June 29, 2015 10:33 PM
> To: Dave Dolson
> Cc: Warren Kumari; captive-portals@ietf.org
> Subject: Re: [Captive-portals] Feedback requested: Charter text.
> 
> 
> On 26-Jun-2015 11:11 am, Dave Dolson  wrote:
>> 
>> A couple of discussion points, since you asked:
>> 
>> 1.
>> "Captive Portal" is a term that seems to be specifically about getting 
>> access to the network.
>> Could this technology embrace other forms of alerts, such as 
>> tornado/tsunami/fire/toxic-spill ?
>> In other words, the ability of the network to interrupt the user with,
>> "I need your eyes on this information, right now"
> 
> Only if the device can handle such alerts (opt-in, somehow).  I mean, we 
> don't want our own fire alarm system interrupted from its communication 
> because of a tornado 10 miles away, and we don't want our Internet-connected 
> door lock interrupted because of a fire (even a fire within the same 
> building).  And we don't want to relive 1987 for our normal web usage, 
> either; 
> https://en.wikipedia.org/wiki/Max_Headroom_broadcast_signal_intrusion.  That 
> is, such interruptions need to be authorized and authenticated.
> 
> tl;dr:  No.
> 
> 
>> 2.
>> On an unrelated note, should probably allow devices without operators or 
>> screens (IoT devices) to fulfill CP requirements.
>> Hence, not just about browsers rendering HTML to humans, but any kind of 
>> client.
>> 
>> 
>> 3.
>> Although the proposed charter doesn't say it, some discussion seems to 
>> indicate this should be a link-layer
>> problem. I.e., a matter for DHCP and the first-hop router. I'd like to see 
>> this posed as an internet-layer
>> problem, hence applicable to all forms of internet access, and made 
>> enforceable by any forwarding device
>> along the path. As a simple example, a device behind a NAT may need to 
>> receive a captive-portal alert from
>> an enforcement point on the other side of the NAT.
> 
> I'm not sure how that would work.  Are you mentioning NAT because of address 
> sharing (NAPT) which makes it difficult/impossible to distinguish separate 
> devices on the public side of a NAPT?
> 
> I would not want any device along the path able to inject itself to become a 
> captive portal; imagine the chaos if a core router did that.
> 
> -d
> 
> 
>> 
>> 
>> I don't know if any of my points warrant changes to the proposed charter. 
>> But if the above are to be
>> specifically excluded, it's probably worth saying so.
>> 
>> 
>> 
>> -Dave
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> -Original Message-
>> From: Captive-portals [mailto:captive-portals-boun...@ietf.org] On Behalf Of 
>> Warren Kumari
>> Sent: Tuesday, June 23, 2015 2:26 PM
>> To: captive-portals@ietf.org
>> Subject: [Captive-portals] Feedback requested: Charter text.
>> 
>> Hi all,
>> 
>> We have a BoF scheduled for the IETF in Prague.
>> 
>> We would like to get a discussion going on some *strawman* charter text.
>> 
>> 
>> -
>> 
>> Captive Portals are used to restrict access to a network until users
>> have purchased access, or accepted Acceptable Use Polices (AUP).
>> They accomplish this by intercepting connections from unauthenticated
>> clients, redirecting them to an authentication server, and then
>> granting access (if satisfied). By developing a standard set of
>> Captive Portal interactions (including simple ways for clients to
>> discover and interact with CPs), we will significantly improve 

Re: [Captive-portals] Feedback requested: Charter text.

[🔓Dan Wing]

On 26-Jun-2015 11:11 am, Dave Dolson  wrote:
> 
> A couple of discussion points, since you asked:
> 
> 1.
> "Captive Portal" is a term that seems to be specifically about getting access 
> to the network.
> Could this technology embrace other forms of alerts, such as 
> tornado/tsunami/fire/toxic-spill ?
> In other words, the ability of the network to interrupt the user with, 
> "I need your eyes on this information, right now"

Only if the device can handle such alerts (opt-in, somehow).  I mean, we don't 
want our own fire alarm system interrupted from its communication because of a 
tornado 10 miles away, and we don't want our Internet-connected door lock 
interrupted because of a fire (even a fire within the same building).  And we 
don't want to relive 1987 for our normal web usage, either; 
https://en.wikipedia.org/wiki/Max_Headroom_broadcast_signal_intrusion.  That 
is, such interruptions need to be authorized and authenticated.

tl;dr:  No.


> 2.
> On an unrelated note, should probably allow devices without operators or 
> screens (IoT devices) to fulfill CP requirements.
> Hence, not just about browsers rendering HTML to humans, but any kind of 
> client.
> 
> 
> 3.
> Although the proposed charter doesn't say it, some discussion seems to 
> indicate this should be a link-layer 
> problem. I.e., a matter for DHCP and the first-hop router. I'd like to see 
> this posed as an internet-layer 
> problem, hence applicable to all forms of internet access, and made 
> enforceable by any forwarding device 
> along the path. As a simple example, a device behind a NAT may need to 
> receive a captive-portal alert from
> an enforcement point on the other side of the NAT.

I'm not sure how that would work.  Are you mentioning NAT because of address 
sharing (NAPT) which makes it difficult/impossible to distinguish separate 
devices on the public side of a NAPT?

I would not want any device along the path able to inject itself to become a 
captive portal; imagine the chaos if a core router did that.

-d


> 
> 
> I don't know if any of my points warrant changes to the proposed charter. But 
> if the above are to be
> specifically excluded, it's probably worth saying so.
> 
> 
> 
> -Dave
> 
> 
> 
> 
> 
> 
> 
> -Original Message-
> From: Captive-portals [mailto:captive-portals-boun...@ietf.org] On Behalf Of 
> Warren Kumari
> Sent: Tuesday, June 23, 2015 2:26 PM
> To: captive-portals@ietf.org
> Subject: [Captive-portals] Feedback requested: Charter text.
> 
> Hi all,
> 
> We have a BoF scheduled for the IETF in Prague.
> 
> We would like to get a discussion going on some *strawman* charter text.
> 
> 
> -
> 
> Captive Portals are used to restrict access to a network until users
> have purchased access, or accepted Acceptable Use Polices (AUP).
> They accomplish this by intercepting connections from unauthenticated
> clients, redirecting them to an authentication server, and then
> granting access (if satisfied). By developing a standard set of
> Captive Portal interactions (including simple ways for clients to
> discover and interact with CPs), we will significantly improve the CP
> user experience, increase security, and simply the CP interceptions.
> This will increase the user completion rate, increase the CP
> interception reliability, and decrease the implementation complexity
> and cost.
> 
> Many of the interception techniques are very similar to
> man-in-the-middle attacks, and, as clients become more secure, are
> increasingly ineffective, leading to a poor user experience. Many of
> the captive portals require a web browser to interact with the
> authentication system, and may require that the user disconnects any
> VPNs, browses to a non-HTTPs site, or similar. In addition, there is
> no standard way to discover the existence of the captive portal, when
> the captive portal has been satisfied, and how much time remains
> before the captive portal restricts access again.
> 
> The Captive Portal (CAPPORT) Working Group will address these (and
> related issues) by defining a standard mechanism for clients to
> interact with Captive Portals, including how to connect to the captive
> portal and how to communicate with it to obtain status information
> such as remaining access time, purchased bandwith class, etc.
> 
> This working group will seek participation and input from browser /
> operating system vendors, captive portal developers and operators.
> One of the known challenges is that some captive portal operators may
> not want to use a standard interaction protocol, preferring to perform
> more intrusive interception and interactions. We are hoping that the
> benefits to CP standardization outlined here are sufficient to not
> only encourage input from CP developers and operators, but also aid in
> deployment.
> 
> Milestones:
> TDB: Initial problem statement / use case document [0]
> TBD: Initial terminology document [1]
> TBD: Initial portal interaction document (perhaps based upon
> h

[Captive-portals] iOS 9 hotspot / captive portal API

[🔓Dan Wing]

First part of this video, https://developer.apple.com/videos/wwdc/2015/?id=717

-d

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] Starting to discuss Captive Portals

[🔓Dan Wing]

On 30-Mar-2015 12:35 PM, Yoav Nir  wrote:
> 
>> On Mar 30, 2015, at 10:07 PM, Warren Kumari  wrote:
>> 
>> On Mon, Mar 30, 2015 at 7:41 AM, Patrick McManus  
>> wrote:
>>> I really appreciate the draft.
>>> 
>>> There is one thing I really like about the draft, as it operates at a dhcp
>>> level the first hint I'm in a CP happens strictly before any connections are
>>> formed.. that should help keep things orderly without imposing delays on
>>> non-CP scenarios. Unfortunately, because it doesn't help with CP state (just
>>> CP enabled network or not) it does add delay for determining state with
>>> some, potentially slow, internet server for hosts behind CP that are already
>>> whitelisted. For instance, every time I open my laptop in a hotel for 24
>>> hours after signing the T&C.
>>> 
>>> I also agree with Yaron's thoughts. I think the document acknowledges a few
>>> problems that it needs to actually deal with to make this practical
>>> 
>> 
>> 
>> Fair. I'm (always) happy to accept suggestions on how to address
>> these... and, of course, even happier to get text :-)
>> 
>>> * Capture status
>> 
>> How about something like requiring that the "Congratulations, you are
>> now connected to the Internet" page contains a magic string (e.g:
>> "CP_SATISFIED_JABBERWOCKY" or "The Magic Words are Squeamish
>> Ossifrage") ? This allows the client to know when it has satisfied the
>> Captive Portal.
> 
> Not sure the portals want your client to know. It took me a while, but I 
> finally figured out why Apple’s scheme was not working in my hotel. When a 
> Mac goes on a new network, it sends a request for one of several pre-defined 
> URLs. They all return the simple string “success”. If they don’t get that, 
> Mac OS pops up a window and shows the user whatever it got instead.
> 
> My hotel would let those requests through so that the system got “success”.

For example of such configuration, see 
http://blog.tanaza.com/blog/bid/318805/iOS-7-and-captive-portal-a-guide-to-captive-portal-requirements

> After that nothing worked until I browsed to some HTTP site and got the 
> captive portal. So I filled in the super secret password that I got with my 
> room key, and got to a web page about all the great stuff at my hotel. So why 
> did my hotel do this? It’s because they wanted me to see that page.

The page would be displayed with the OS's restricted browser, too, and you 
could interact with the page.  Also likely they wanted you to use a full 
browser (JavaScript, cookies, perhaps also password autofill), rather than the 
restricted browser the OS likes to use.

-d

> With Apple’s scheme, the moment the system detects that I’m on the real 
> Internet, it makes the special window go away so that I can get some work 
> done. Your CP_SATISTISFIED_JABBERWOCKY would allow the OS to remove the 
> special window, and then I don’t get to see what’s on that page. 
> 
> I’m not saying that it’s a bad thing to specify, but we should realize that 
> captive portals, much like websites and OS vendors want to control your 
> experience.
> 
> Yoav
> 
> ___
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals


___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals