NETMANIAS

TECH-BLOG

Please visit www.netmanias.com to view more posts

Captive portal-based user authentication in

KT, SK Telecom and LG U+'s Wi-Fi hotspots
March 10, 2015 | Dr. Chris Yoo (tech@netmanias.com)

As noted in the previous post, currently there are two types of user authentication in the Wi-Fi networks
operated by Korean operators: IEEE 802.1X-based and captive portal-based authentication. 802.1X-based
authentication targets primarily mobile devices with an operator's USIM card, whereas captive portal-based
authentication to be discussed here is used to attract users without a permanent contract with an operator
(credit card payments, vouchers, time-limited access, etc.).
SSIDs that the Korean big 3 operators provide through captive portal-based authentication procedure are:

KT: ollehWiFi

SK Telecom: T wifi zone

LG U+: U+zone_FREE

Call flow in the big 3's captive portal-based authentication is very similar. So, we will use KT's ollehWiFi to
explain the authentication logics.

Netmanias Tech-Blog: Captive portal-based user authentication in KT, SK Telecom and LG U+'s WiFi hotspots

Wi-Fi

Captive Portal

Wi-Fi

Web

AAA

AP
Netbook

Hotspot AP

MAC=A

MAC = B
Public IP = 210.217.36.176

1 Beacon
SSID=ollehWiFi, AP MAC address=B, Security=Open

2 User selects ollehWiFi (with no lock icon)

3 802.11 Association
SSID=ollehWiFi

4 No 802.1x authentication for this SSID

5 No Security (No User Data Encryption)

AP acts as DHCP Server, and delivers
Private IP address to MS (AP supports PAT/NAT)

6 IP Allocation (DHCP)

DHCP Sever
Device gets Private IP address 172.30.78.34
7 HTTP GET
http://www.youtube.com

9 HTTP 302 Found

Location: http://first.wifi.olleh.com/webauth/index.html?
ip=210.217.36.176&mac=A&
url=http://www.youtube.com&ssid=ollehWiFi&ap_mac=B

8 Hot Lining (HTTP 302 Redirection)

HTTP traffic is redirected to KT ollehWiFi Captive Portal

DHCP, DNS and ARP traffic are permitted
Other types of traffic (e.g., ftp, telnet, ) are dropped

10 HTTP GET
http://first.wifi.olleh.com/webauth/index.html?ip=210.217.36.176&mac=A&
url=http://www.youtube.com&ssid=ollehWiFi&ap_mac=B

11 HTTP Login Page

12 User types Username & Password
13 HTTPS (HTTP over SSL) session establishment
14 HTTPS POST
Username, Password,
Referer: http://first.wifi.olleh.com/webauth/index.html?ip=210.217.36.176&mac=A&
url=http://www.google.com&ssid=ollehWiFi&ap_mac=B

15 Login Information
Username, Password

16 [RADIUS] Access Request

Username, Password

18 [RADIUS] Access Accept

17 AAA
authenticates User
based on Username
& Password

19 Remove HTTP Redirection Rule

20 Login Result
21 HTTPS Login Result

Username, Password

22 [RADIUS] Accounting Request: Start

User-Name, Framed-IP-Address=172.30.78.34,
Calling-Station-Id=A, # of UL/DL bytes, # of UL/DL packets, etc

23 Internet Access
UL: SIP=172.30.78.34

...

PAT(NAT)
UL: SIP=220.217.36.176

...

Internet

Figure 1. Captive Portal-based Authentication and Internet Access Flow in KT's ollehWiFi
1.

In the figure above, an access point (AP) broadcasts a beacon frame to a plurality of stations
periodically. The frame at this time contains SSID (ollehWiFi), AP's MAC address (B), security
information (open) and so on. So, when a user searches for a wireless LAN on his device, SSID(s)
appears along with locked or unlocked information next to them (encrypted networks will show a
lock icon to the right of the SSID while open networks will not).

Netmanias Tech-Blog: Captive portal-based user authentication in KT, SK Telecom and LG U+'s WiFi hotspots

2.

The user selects ollehWiFi (with no lock icon) to join.

3.

Then the station goes through 802.11 association procedure with the AP. As explained last time, this
procedure is the same as "connecting a LAN cable to a PC" in a wired network.

4.

As ollehWiFi AP's security is set open, the station skips 802.1X authentication procedure and
performs IP allocation procedure in Step 6 instead.

5.

Because 802.1X-based authentication procedure is skipped, no user data is encrypted or integrityprotected in the airlink between the station and the AP.

6.

The station sends a DHCP message (DHCP Discover/Request) to have the AP allocate an IP address to
it. Upon receipt of the message, the AP, acting as a DHCP server, allocates an IP address to the
station (DHCP Offer/Ack). As the IP address allocated by the AP is a private IP, the AP acts as
PAT/NAT (feature that translates multiple private IP addresses into one public IP address).

7.

Now that the station has an IP address as well, the user attempts to access a website (e.g.
www.youtube.com).

8.

ollehWiFi AP blocks all IP communications except DHCP, DNS and ARP messages for unknown users
(identified by station MAC or IP address), and redirects HTTP connections to a pre-configured captive
portal (KT web authentication server).

9.

The HTTP 302 Found message delivered by ollehWiFi AP to the station includes:

Captive portal URL: http://first.wifi.ollehWiFi.com/webauth/index.html

AP's IP address: 220.217.36.176

Station's MAC address: A

URL user attempted to access: http://www.youtube.com

SSID: ollehWiFi

AP's MAC address: B

10. The station sends HTTP GET message to the URL shown in Location field of the received HTTP 302
Found message, i.e. captive portal.

http://first.wifi.ollehWiFi.com/webauth/index.html?ip=220.217.36.176&mac=A&url=http://ww
w.youtube.com&ssid=ollehWiFi&ap_mac=B

11. The captive portal delivers a login page to the station via HTTP 200 OK message.
12. The user enters the user credentials (username and password) obtained from KT on the login page.
13. As the Wi-Fi airlink is not encrypted, a HTTPS (SSL over HTTP) session is created between the station
and captive portal to ensure secure delivery of the user credentials.
14. Now the user credentials are securely delivered to the captive portal via HTTPS POST message.
15. The captive portal checks the IP address of its serving AP obtained in Step 14, and forwards the user
credentials to the AP. At this time, interfaces between the captive portal and AP will probably be
determined according to the operator-specified method (non-standard).
16. Upon receiving the user credentials, the AP forwards them to AAA via Access Request message,
requesting for user authentication.
17. At AAA, user credentials information of this ollehWiFi user is already provisioned. So AAA, based on
this information, decides whether the authentication succeeded or failed.
18. AAA notifies the AP of the successful authentication via Access Accept message.
19. The AP removes the HTTP redirection rule applied to the user.
20. The AP notifies the captive portal of the successful authentication.

Netmanias Tech-Blog: Captive portal-based user authentication in KT, SK Telecom and LG U+'s WiFi hotspots

21. As a response to the HTTP GET message in Step 14, the captive portal forwards the authentication
result page to the user's station via HTTP 200 OK message.
22. From now on, the AP begins sending accounting messages to AAA on a regular basis to keep track of
Internet traffic usage statistics on the authenticated station.
23. Now, the user has Internet access, but the Internet data he exchange over the Wi-Fi airlink is not
protected (neither integrity-protected nor encrypted). So, he should be careful because someone
might have access to the data packets.
Figures 2 ~ 4 below are Wireshark-captured images of HTTP 302 Found messages (as sent in Step 9 of Figure 1)
that are sent from APs to stations in the Korean big 3 operators' networks. We can see the messages all
include pretty similar information.

Figure 2. HTTP 302 Found Message from KT ollehWiFi AP to station

HTTP 302 Redirect from SKT AP (T wifi zone) to MS (STA)

Redirected URL

AP IP Address

MS MAC Address

User Requested URL

AP MAC Address

Figure 3. HTTP 302 Found Message from SK Telecom T wifi zone AP to station

Netmanias Tech-Blog: Captive portal-based user authentication in KT, SK Telecom and LG U+'s WiFi hotspots

Figure 4. HTTP 302 Found Message from LG U+ U+zone_FREE AP to station

Netmanias Research and Consulting Scope

99

00

01

02

03

04

05

06

07

08

09

10

11

12

13

eMBMS/Mobile IPTV
CDN/Mobile CDN
Transparent Caching
BSS/OSS

Services

Cable TPS
Voice/Video Quality
IMS
Policy Control/PCRF
IPTV/TPS
LTE

Mobile
Network

Mobile WiMAX
Carrier WiFi
LTE Backaul
Data Center Migration
Carrier Ethernet
FTTH

Wireline
Network

Data Center
Metro Ethernet
MPLS
IP Routing

CDN
Transparent
Caching

Analysis

Networks

eMBMS

LTE
IMS
Infrastructure Services

Analyze trends, technologies and market

Report
Technical documents
Blog
One-Shot gallery

Concept Design
DRM

POC

Training

Wi-Fi

We design the future

protocols

IP/MPLS

We design the future

Carrier Ethernet

We design the future

Consulting

Visit http://www.netmanias.com to view and download more technical documents.

Future

About NMC Consulting Group (www.netmanias.com)

NMC Consulting Group is an advanced and professional network consulting company, specializing in IP network areas (e.g., FTTH, Metro Ethernet and IP/MPLS), service
areas (e.g., IPTV, IMS and CDN), and wireless network areas (e.g., Mobile WiMAX, LTE and Wi-Fi) since 2002.
Copyright 2002-2015 NMC Consulting Group. All rights reserved.