Home | Reports | Technical Documents | Tech-Blog | One-Shot Gallery | Korea ICT News | Korea Communication Market Data | List of Contributors | Become a Contributor |    
 
 
Section 5G 4G LTE C-RAN/Fronthaul Gigabit Internet IPTV/Video Streaming IoT SDN/NFV Wi-Fi KT SK Telecom LG U+ Network Protocol Samsung   Korean Vendors
 
CHANNELS     HFR    |  Mobile Fronthaul Solution  |  Carrier Ethernet Solution  | Resources        
CHANNELS     ZARAM    |  XGSPON 10G SFP+ ONT  |  Use cases  | Evolution of FTTH Access Network    

 

Captive portal-based user authentication in KT, SK Telecom and LG U+'s Wi-Fi hotspots
March 10, 2015 | By Chris Yoo (tech@netmanias.com)
Online viewer:
Comments (1)
4

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
 

Abhay Sapru 2015-05-20 17:37:08

Can i get the pcap trace of the above scenario you can send it to me at abhay_sapru@yahoo.co.in,that would be helpful for better understanding.Actually i wanted to understand the tcp part handling in this case.

Thank you for visiting Netmanias! Please leave your comment if you have a question or suggestion.
View All (823)
4.5G (1) 5G (89) AI (6) AR (1) ARP (3) AT&T (1) Akamai (1) Authentication (5) Big Data (2) Blockchain (3) C-RAN/Fronthaul (17) CDN (4) CPRI (4) Carrier Ethernet (3) China (1) China Mobile (2) Cisco (1) Cloud (5) CoMP (6) Connected Car (4) DHCP (5) EDGE (1) Edge Computing (1) Ericsson (2) FTTH (6) GSLB (1) GiGAtopia (2) Gigabit Internet (19) Google (7) Google Global Cache (3) HLS (5) HSDPA (2) HTTP Adaptive Streaming (5) Handover (1) Huawei (1) IEEE 802.1 (1) IP Routing (7) IPTV (21) IoST (3) IoT (55) KT (43) Korea (19) Korea ICT Market (1) Korea ICT Service (13) Korea ICT Vendor (1) LG U+ (18) LSC (1) LTE (78) LTE-A (16) LTE-B (1) LTE-H (2) LTE-M (3) LTE-U (4) LoRa (7) MEC (3) MPLS (2) MPTCP (3) MWC 2015 (8) NB-IoT (6) Netflix (2) Network Protocol (21) Network Slicing (4) New Radio (9) Nokia (1) OSPF (2) OTT (3) PCRF (1) Platform (2) QoS (3) RCS (4) Roaming (1) SD-WAN (17) SDN/NFV (71) SIM (1) SK Broadband (2) SK Telecom (35) Samsung (5) Security (16) Self-Driving (1) Small Cell (2) Spectrum Sharing (2) Switching (6) TAU (2) UHD (5) VR (2) Video Streaming (12) VoLTE (8) VoWiFi (2) Wi-Fi (31) YouTube (6) blockchain (1) eICIC (1) eMBMS (1) iBeacon (1) security (1) telecoin (1) uCPE (2)
Password confirmation
Please enter your registered comment password.
Password