WLANs. Those networks are historically problematic towards both sides: Provider and Client.
Due to WiFi nature, there’s not much to do in public environment to ensure Client security when connected to public AP. Even if AP is able to use strong security (e.g. PEAP with TLV crypto binding), it will not help, if Client can be convinced by MitM to use weaker security. Since public WLANs are intended to serve virtually anyone, they do not limit Clients to only those, who support particular type of security (down to some logic limit, like EAP-MSCHAP or similar). Protecting Client’s link to the AP, is usually allowed to go to the lower default. So Client is always in a risk of connection to some rouge AP. The most safe thing here, will be – not to provide sensitive data on connection establishment, so that attacker would not gain from the attack. All this more dangerous for enterprise WLANs, where User can be synchronized with AD or corporate apps login, and less for public WLANs.
From other side, real AP owner of, e.g. some regular public place like hotel, is interested to limit access only to its customers, and for limited time, due to his will to provide better service.
Usual practice, is setting a password, that is provided to a customer along with the order, key or any other standard interaction.
Passwords are relatively weak. Setting strict password policy makes it harder to maintain and less friendly to use. And still, passwords are fished out, broken by sniffing and offline dictionary attacks, or just stolen.
So, how a client can be allowed access to particular AP, for limited timeframe and still to have good user experience?
In other words, how can decision making infrastructure be made reliable, fast and scalable?
To get to a possible solution, I will provide some technical background first, and then it will be easier to prove the point.
Authentication Authorization and Accounting, is a framework to define criteria of access to network resources.
The term is used in Networking equipment. Supporting device could be even called AAA server, where each “A” will represent a set of configurations.
A standard for AAA, AP backhaul client-server network protocol, that manages network access, in Client initiated flow
Typical network that uses RADIUS for AAA, comprises Network Access Server (NAS) , RADIUS server and custom Authentication process, intended to return Success/Fail response to the RADIUS server in response to provided User authentication data.
Network Access Server is usually a device, that has PPP interface towards Clients and RADIUS client to communicate to RADIUS server (all can physically be installed on one machine). So functionally, authentication-vise, NAS can be considered as a bridge for AAA network access management.
Widely used, point-to-point protocol, that defines direct connection between two nodes. Has its own security extensions (EAP, PEAP etc), that support variety of authentication options. The EAP is responsible to request a Client for authentication response, once link between peers has been established. In public open networks, this is frequently bypassed (allowed in standard), and Client identity is considered valid by default.
So, in order to satisfy the requirement (provide reliable way of identifying Client for limited time), system should create logical connection between Client device and Authentication service:
There are basically two options:
Here how it works for both options:
Why not to use self-signed cert? The certificate shall be valid and verifiable, publicly trusted. Otherwise the mobile OS will just not allow it into the secure storage.
Proposed solution allows creating strong, manageable Client identity in a minute, with easy integration into existing networks, and with great user experience.