Subject: [dhcwg] "captive portal" issues addressed ?

From: =JeffH <[email-masked]>
Date: Wed, 07 Mar 2012 11:18:14 -0800

fyi, I ran across this article..

Big Changes Coming To Wi-Fi
By Stewart Wolpin
Published Feb 6, 2012
http://tech.lifegoesstrong.com/print/article/big-changes-coming-wi-fi

..which points off to this stuff..

Bringing the Cellular Roaming Experience to Wi-Fi
http://blogs.cisco.com/tag/hotspot-2-0/

The Future of Hotspots: Making Wi-Fi as Secure and Easy to Use as Cellular
https://www.cisco.com/en/US/solutions/collateral/ns341/ns524/ns673/white_paper_c11-649337.html
https://www.cisco.com/en/US/solutions/collateral/ns341/ns524/ns673/white_paper_c11-649337.pdf

..which has these sections (attached below)..

  Next-Generation Hotspot Network Discovery and Selection

  MSAP: Making Next-Generation Hotspots Even Better with New Service
  and Revenue Opportunities

..which seems to me to address (if deployed in hotspots and clients) the 
"captive portal" issue.

what do you folks think?

thanks,

=JeffH
------

Next-Generation Hotspot Network Discovery and Selection
IEEE 802.11u, the amendment addressing "Interworking with External Networks," 
was completed by the 802.11u task group in mid-2010 and approved by the IEEE 
for publication in February 2011. The purpose of the amendment is to provide an 
effective interface between an IEEE 802.11 access network and carrier networks. 
The amendment adds to IEEE 802.11 the following services (this is not a 
comprehensive list):

• Network discovery and selection

– Provides for the discovery of suitable networks (preassociation) through the 
advertisement of access network type {private network, free public network, 
for-fee public network}, roaming consortium, and venue information.

– Generic Advertisement Service (GAS), which provides for Layer 2 transport of 
an advertisement protocol's frames between a mobile device and a server in the 
network prior to authentication. The access point is responsible for the relay 
of a mobile device's query to a server in the carrier's network and for 
delivering the server's response back to the mobile.

– Provides Access Network Query Protocol (ANQP), which is a query and response 
protocol used by a mobile device to discover a range of information, including 
the hotspot operator's domain name (a globally unique, machine searchable data 
element); roaming partners accessible via the hotspot along with their 
credential type and EAP method supported for authentication; IP address type 
availability (for example, IPv4, IPv6); and other metadata useful in a mobile 
device's network selection process.

• QoS map distribution. This provides a mapping between the IP's differentiated 
services code point (DSCP) to over-the-air Layer 2 priority on a per-device 
basis, facilitating end-to-end QoS.
The following is an exemplary, simplified sequence of events used by an IEEE 
802.11u-capable mobile device to authenticate with a hotspot:
1. The mobile device comes within radio range of one or more hotspots and 
receives their beacons. These beacons indicate support for the IEEE 802.11u 
protocol via the Interworking element. The SSID element in the beacon provides 
the Wi-Fi network name. (In the next steps, it's assumed that the mobile device 
doesn't recognize any of the received SSIDs.)
2. The mobile device uses GAS to post an ANQP query to an access point from 
each of the SSIDs discovered in step 1. In response, each access point provides 
the hotspot operator's domain name and network access identifier (NAI) Realm list.
3. The mobile device next retrieves its credential from local storage to get 
the realm with which it can authenticate. The mobile device then compares that 
realm to the list of roaming partner's realms it retrieved in step 2 (in the 
NAI Realm list). If there is a match, the mobile device knows it should be able 
to successfully authenticate with that network. If there is more than one 
match, the mobile device uses operator policy to determine which Wi-Fi network 
to join.
4. The mobile device next retrieves its operator policy for network selection 
from local storage and looks up an ordered list of preference level and domain 
name pairs for each of its roaming partners. The mobile device then compares 
the hotspot operator's domain names received in step 2 with this list and 
selects the network having the highest preference level.
5. The mobile device authenticates to that network using its credential. In 
cases where the mobile device is in possession of more than one credential (for 
example, the mobile has a SIM and username/password credentials), it can use 
the NAI Realm list to learn the acceptable credential type(s) and EAP method(s).
As we've just described, using ANQP with GAS, a mobile device can query the 
network prior to authentication to determine if the hotspot is operated by one 
of its roaming partners, as well as the EAP method and credential type to use. 
A mobile device's connection manager can now autonomously (that is, without 
user intervention) determine which hotspot to select taking into account 
operator policies, authenticate to that Wi-Fi network, and establish link-layer 
security using WPA2-Enterprise. Wi-Fi has become as easy-to-use and as secure 
as 3G cellular!

MSAP: Making Next-Generation Hotspots Even Better with New Service and Revenue 
Opportunities
Many venues that have deployed Wi-Fi access networks don't fall under the 
colloquial definition of hotspot (such as coffee shops, airports, and hotels). 
For example, Wi-Fi is being deployed in sports stadiums, retail shopping malls, 
and other public places. Often, these venues wish to deploy local services not 
accessible through the public Internet. Increasingly, carriers are operating 
these networks on behalf of venue owners as part of a managed service offering.
Mobility Services Advertisement Protocol (MSAP) is a protocol for service 
discovery, enabling the connection of users to venue services. Because MSAP is 
transported via IEEE 802.11u GAS, mobile devices can query for local services 
prior to authenticating to a Wi-Fi network. Mobile devices performing an MSAP 
query securely retrieve icons and service URLs; the mobile device's UI displays 
the icons (when enabled/requested by the user). When the user clicks on the 
icon, the mobile device launches an application, such as a browser to the URL, 
thereby accessing the service. In so doing, users are securely, easily, and 
immediately connected to venue-based services. Examples of such services in a 
stadium include display of a stadium map showing food kiosks and restrooms, 
looking up player statistics, and watching instant replays.
MSAP messages are Simple Object Access Protocol (SOAP) methods carrying XML 
payloads. An MSAP client (software on the mobile device) queries an MSAP server 
for service advertisements. Service advertisements include an icon, URL, 
related metadata, and a digital signature. The XML digital signature is used to 
verify the authenticity and integrity of the service advertisements. This is 
critical, as service advertisements are delivered prior to authentication; 
therefore, there is no Layer 2 security association that can protect their 
integrity.

---
end

---

From: perl-list <[email-masked]>
Date: Wed, 07 Mar 2012 15:24:03 -0500 (EST)

What is(are) the "captive portal" issue(s) and how does this address it? 
Just curious... 

----- Original Message -----

> From: "=JeffH" <[email-masked]>
> To: [email-masked]
> Cc: "Julian Reschke" <[email-masked]>, "Mark Nottingham"
> <[email-masked]>
> Sent: Wednesday, March 7, 2012 2:18:14 PM
> Subject: [dhcwg] "captive portal" issues addressed ?

---

From: Simon Hobson <[email-masked]>
Date: Wed, 7 Mar 2012 21:59:03 +0000

>What is(are) the "captive portal" issue(s) and how does this address it?

Wifi hotspot experience today ...
Your device connects to a wireless network and "nothing works". You 
have to open up a web browser, attempt to connect to any random web 
page, and the hotspot controller will intercept your request and 
serve you up the captive portal login page. Only when you've logged 
in (with a different username/password and user experience for each 
different provider) will your internet connection work properly.

IIRC, having read about this a little while ago, the proposals are 
for some common standards etc that would allow the client to 
automatically authenticate with any hotspot you have permission to 
use (ie any of those your service provider has a commercial agreement 
with).  Thus you get the "cellular experience" where you don't have 
any concept of which base station your device is working through, 
only that "it works" whenever you are in range of any base station 
your provider operates (or is operated by another provider your own 
provider has an agreement with).

-- 
Simon Hobson

Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.

---

From: <[email-masked]>
Date: Wed, 7 Mar 2012 22:14:36 +0000

>provider has an agreement with).

The proposed standards for "cellular experience" is Hotspot 2.0 which is
now being done in Wifi alliance (WFA).

>_______________________________________________
>dhcwg mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Wed, 7 Mar 2012 22:37:13 +0000

What they're talking about here seems not to be related to captive portals per se, but rather to captive customers. As an end user, this sounds like a really bad idea.   I'm sure there's a ton of money in it.

Why on earth would I want every WiFi hotspot in the world to be able to immediately identify who I am, before I even agree to connect?

---

From: perl-list <[email-masked]>
Date: Wed, 07 Mar 2012 20:02:26 -0500 (EST)

Agreed. I was just wondering what the issue surrounding a captive portal was. Windows, for example, even detects that you need to authenticate and pops a bubble down by the clock prompting you to do so. 

With the continued expansion of the web browser as the portal of nearly everything internet for many people, I would suspect that people will have less and less of this captive portal issue. 

btw, does this actually have anything to do with DHCP, or is this just off topic? 

----- Original Message -----

> From: "Ted Lemon" <[email-masked]>
> To: "=JeffH" <[email-masked]>
> Cc: "Julian Reschke" <[email-masked]>, "<[email-masked]>"
> <[email-masked]>, "Mark Nottingham" <[email-masked]>
> Sent: Wednesday, March 7, 2012 5:37:13 PM
> Subject: Re: [dhcwg] "captive portal" issues addressed ?

> What they're talking about here seems not to be related to captive
> portals per se, but rather to captive customers. As an end user,
> this sounds like a really bad idea. I'm sure there's a ton of money
> in it.

> Why on earth would I want every WiFi hotspot in the world to be able
> to immediately identify who I am, before I even agree to connect?

---

From: Ted Lemon <[email-masked]>
Date: Thu, 8 Mar 2012 02:50:20 +0000

On Mar 7, 2012, at 8:02 PM, perl-list <[email-masked]<mailto:[email-masked]>>
 wrote:
Agreed.  I was just wondering what the issue surrounding a captive portal was.  Windows, for example, even detects that you need to authenticate and pops a bubble down by the clock prompting you to do so.

Mac does too, as does iOS.   Not sure about Android.

Yes, it's essentially a solved problem.

It did back when we needed to solve the captive portal problem using DHCP authentication of some sort.   However, at this point the two issues have, as you suggest, essentially become orthogonal.   I think there's still a use for DHCP authentication, but now it's for replacing PPPoE, rather than for replacing captive portals.

---

From: perl-list <[email-masked]>
Date: Thu, 08 Mar 2012 08:36:30 -0500 (EST)

----- Original Message -----

> To: "perl-list" <[email-masked]>
> Cc: "dhcwg" <[email-masked]>
> Sent: Wednesday, March 7, 2012 9:50:20 PM

> It did back when we needed to solve the captive portal problem using
> DHCP authentication of some sort. However, at this point the two
> issues have, as you suggest, essentially become orthogonal. I think
> there's still a use for DHCP authentication, but now it's for
> replacing PPPoE, rather than for replacing captive portals.

Agree with replacing PPPoE. DHCP authentication would be quite interesting in the environment at the company I work for.