|
Regarding the AP/client identification, this is the reason I suggested in an earlier email, https://mailarchive.ietf.org/arch/msg/captive-portals/RPwEIuLlW6ZSLmEyaqfxgDrF88Q " Posting to the create_href: POST http://<server>/capport/sessions (Accept: application/json) { "identity": "<USERNAME>"} … The USERNAME could be DHCP option-12 value or MAC address or ? " I didn’t know exactly what this identity should be. Maybe multiple identity options are useful. -Dave From: Captive-portals [mailto:[email protected]]
On Behalf Of David Bird Welcome and thanks for the input James! Comments in-line. On Tue, Apr 18, 2017 at 8:21 AM, James Wood <[email protected]> wrote: [snip] No doubt, Wi-Fi security is important in public access, but I'd argue outside the scope of the WG. While captive portals are often used on Open Wi-Fi, they are not limited to public access (there are LTE use-cases, for example). Also, security
in public access transcends L1 security -- do you trust any wired LAN you plug into while in public places? HS2.0 (more or less) solves the public Wi-Fi security problem in that users trust their providers (albeit to varying degrees) and their providers have
a relationship with the HS2.0 network provider. Even if deployed, this doesn't address situations where users have no trust relationship with the network provider and still want Wi-Fi (as most people, they assume Apps are increasingly using TLS and provide
end-to-end security).
Yes, we need to fix this! It is disturbing that vendors commonly hijack https even with the security errors.
Very common problems.
Managing the walled garden configuration is probably also outside the code of the WG. I don't think we should have any API inform the client directly of the walled garden as that information could be misleading, or wrong. I do agree that
the real issue is having the walled garden configuration synchronized with the NAS/AP ... however, vendors do their own proprietary ways of doing this already.
This is an area where I expect discussion. If the DHCP server is integrated with the NAS, then the RFC7710 URL could contain all the necessary session-specific query string parameters and the additional parameters are just added. It is
also possible that the RFC7710 URL is something like
http://<NAS-IP>/redirect which the NAS responds to with a redirect to
https://<real-portal-domain>/... with all the necessary parameters. This becomes implementation specific, but all the information required can be captured one way or another.
I think Hotspot 2.0 has its place and will get deployed... and addresses, imho, the security of Wi-Fi in public access. It is doing do with security and "auto-connect" in mind. One issue I think that remains is that post authentication,
HS2.0 doesn't necessarily protect the data-plane on the LAN or send it back to the operator. I think operators will be selective in which networks they trust and partner with. I don't think this will replace captive portals on Open Wi-Fi or elsewhere.
|