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.
 

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). 
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 integrity-protected 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: https://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=https://www.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.
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
 

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

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