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

Re: [Captive-portals] A new draft / idea - draft-wkumari-capport-icmp-unreach



To clarify, there is a CP access controller (let's call this CP-NAS) and a CP web application (and this CP-WEB). The DHCP option could return the IP address of the CP-NAS (if not the same as the default gateway). We can then define a .well-known URL, such as http://CP-NAS/.well-known/capport-redirect, which the client can use to learn the (possibly device and session specific) URL to the CP-WEB application. The CP-NAS URL is always HTTP and only does a 302 redirect to the CP-WEB application. This provides a convenient and standard way for the client to pick-up the CP-WEB URL (with all necessary query string parameters added by the CP-NAS) without having to "guess" a URL outside of the walled garden or wait for the user to visit a HTTP site. The CP-WEB URL can, and should, be HTTPS if handling any user data (though, perhaps not a MUST as a Terms of Service only wouldn't necessarily require https). 

* Note: CoovaChilli already has this type of internal URL (http://chilli-ip:uam-port/prelogin). 

I'm not sure it belongs in RFC, but ideally, I'd like to see Clients NOT use a limited (sandbox) browser when a CP-WEB is using HTTPS. TLS should be providing all the necessary security and Clients using sandboxed browsers for CP interaction is WHY hotspot providers circumvent OS CP detection. (I actually don't see much real benefit in a sandbox browser for HTTP either. A "bad" network could just also whitelist CP detection URLs, or even just offer pure Open WiFi, to prevent the sandbox browser from being used. However, if vendors do still use a sandboxed browser for HTTP CP-WEB, it will just encourage networks to use HTTPS, which is probably a good thing.)



On Tue, Oct 6, 2015 at 5:53 AM, Michael Richardson <[email protected]> wrote:

David Bird <[email protected]> wrote:
    > necessary information (like client MAC address, IP address, etc) to
    > format the CP URL that otherwise would have been in a 302 redirect. so,
    > the CP web application can, and should, be using HTTPS.

I don't know how it can use HTTPS given current certificate options.

The only identity that the CP has that the client can verify is it's MAC
address, and that's not currently an option for certificates. (I've argued
that it should be: iLOMs and other (home) appliances have the same problem)

After the 302 redirect, I can see how it could be a redirect *to* a https URL.

--
Michael Richardson <[email protected]>, Sandelman Software Works
 -= IPv6 IoT consulting =-




_______________________________________________
Captive-portals mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/captive-portals