Re: [dhcwg] "captive portal" issues addressed ?

[=JeffH <[e-mail]>]

 > What is(are) the "captive portal" issue(s) and how does this address it?

from <https://en.wikipedia.org/wiki/Captive_portal> [0] ..

   "The captive portal technique forces an HTTP client on a network to see a 
special web page (usually for authentication purposes) before using the 
Internet normally. A captive portal turns a Web browser into an authentication 
device.[1] This is done by intercepting all packets, regardless of address or 
port, until the user opens a browser and tries to access the Internet. At that 
time the browser is redirected to a web page which may require authentication 
and/or payment, or simply display an acceptable use policy and require the user 
to agree. Captive portals are used at many Wi-Fi hotspots, and can be used to 
control wired access (e.g. apartment houses, hotel rooms, business centers, 
"open" Ethernet jacks) as well."

The wikipedia article lists some of the more common approaches, as well as 
outlines limitations.

The main issue is that "There is more than one way to implement a captive 
portal."  Thus they all end up working a bit differently, and there's also 
conflicts with end-to-end security such as HTTP Strict Transport Security 
(HSTS), e.g. if one's browser will only use TLS/SSL to contact some website you 
use to attempt to get the captive portal page to load in your browser, but the 
captive portal you're behind doesn't use TLS, and doesn't pass it through, you 
end up just sitting there with a hung browser, unless you think of some other 
website to try to contact that is not HTTPS-only.

There's been various modest attempts in the IETF to standardize something that 
addresses captive portals, e.g. draft-nottingham-http-portal-02 [1], superseded 
by section 6.1 "The 511 Status Code and Captive Portals" of 
draft-nottingham-http-new-status-04 [2].

Then there's also the Microsoft Windows use of DHCP option 252 [3] in "Web 
Proxy Autodiscovery Protocol (WPAD)", which is not fully standardized, and has 
some spotty coverage (outside of the Microsoft world), AFAICT [4, 5]. WPAD was 
a work item of the WREC (Web Replication and Caching) working group (WG), which 
morphed into the WEBI (Web Intermediaries) WG. The two serial WG's produced two 
"Informational" RFCs before disbanding [6, 7], as well as this I-D [8]  (I 
haven't reviewed all of them in detail, tho they don't mention the term 
"captive portal").

HTH,

=JeffH


[0] Captive portal
     https://en.wikipedia.org/wiki/Captive_portal

[1] The Network Authentication Required HTTP Status Code
     https://tools.ietf.org/html/draft-nottingham-http-portal

[2] Additional HTTP Status Codes
     https://tools.ietf.org/html/draft-nottingham-http-new-status

[3] Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) 
Parameters
 
http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xml

[4] Web Proxy Autodiscovery Protocol (WPAD)
     https://en.wikipedia.org/wiki/Web_Proxy_Autodiscovery_Protocol

[5] RE: Auto-detect in Firefox with a wpad file??? - 15.Apr.2009 6:27:28 AM
     http://forums.isaserver.org/fb.aspx?m=2002085031

     Better Proxy Settings… Bluecoat, wpad, proxy.pac & dhcp option 252
 
http://www.linickx.com/960/better-proxy-settings-bluecoat-wpad-proxypac-dhcp-option-252

     DHCP, 'wpad' option 252  (Apple Support Communities)
     https://discussions.apple.com/thread/2309560?start=0&tstart=0

     Microsoft Internet Security and Acceleration Server 2004
     Automatic Discovery for Firewall and Web Proxy Clients
     http://technet.microsoft.com/en-us/library/cc713344.aspx


[6] Internet Web Replication and Caching Taxonomy
     https://tools.ietf.org/html/rfc3040

[7] Known HTTP Proxy/Caching Problems
     https://tools.ietf.org/html/rfc3143

[8] Known HTTP Proxy/Caching Problems
     https://tools.ietf.org/id/draft-ietf-wrec-known-prob-03.txt

---
end