Regarding non-browser clients, even non-HTTP clients, and considering this is the IETF, it seems reasonable to find an IP-layer solution vs. an HTTP-layer solution.
E.g., a new ICMP/ICMP6 error code to indicate the host is walled, with a pointer to the method to authenticate in the payload. This could be an extension to "Network Unreachable", or a new code. ICMP messages are handled by the O/S, and could trigger an authentication work-flow appropriate to the device, whether it be a human-interface device like a tablet or a head-less IOT device. E.g., suppose the a VoIP phone becomes walled during a call. Outgoing packets are answered with an ICMP message; the O/S immediately performs the authentication using previously-provided credentials, and the call continues shortly thereafter. If the credentials fail, the user can be presented with a window or browser. The ICMP payload would be a standard format, and could have security features to avoid spoofing. I guess I'm jumping ahead of the problem statement, but I think the "Non-Browser Clients" issue could be changed to "Non-HTTP Clients", providing a huge win. -Dave -----Original Message----- From: Captive-portals [mailto:[email protected]] On Behalf Of Martin Thomson Sent: Wednesday, March 02, 2016 7:25 PM To: Livingood, Jason Cc: Mark Nottingham; [email protected] Subject: Re: [Captive-portals] Comments on draft-nottingham-capport-problem-00 On 3 March 2016 at 11:16, Livingood, Jason <[email protected]> wrote: > 3.0, Feel free to take a look at the text in Section 12 of RFC 6108 and > use some of that text. You got the gist of it in the Non-Browser Clients > sub-section though (https://tools.ietf.org/html/rfc6108#section-12) This raises an interesting point about internet dot org by facebook. I wonder if there are any lessons to be learned from that as well. _______________________________________________ Captive-portals mailing list [email protected] https://www.ietf.org/mailman/listinfo/captive-portals _______________________________________________ Captive-portals mailing list [email protected] https://www.ietf.org/mailman/listinfo/captive-portals
