Subject: [Captive-portals] Alternative authentication mechanism to meet captive portal needs?

From: David Illsley <[email-masked]>
Date: Fri, 9 Oct 2015 15:48:33 +0100

Hi all,
Apologies if this is a silly question (and if I missed it in the archives).
Has anyone (anywhere) considered if there's a new (EAP?) authentication
mechanism that would meet at least some of the needs of deployers of
captive portals? eg allow users to agree to an acceptable use policy, see a
logo, and enter their email address?

I know its potentially a bigger change than some of the others suggested,
but if these requirements aren't going anywhere, it might be worth the
long-term investment.

David

---

From: [email-masked]
Date: Fri, 09 Oct 2015 16:58:19 +0200

Hello,

being a huge EAP-based roaming consortium, eduroam is facing those  
same ToU/branding questions.

We settled for an out-of-EAP approach to show logo and ToU during the  
provisioning phase.

Take a look at  
https://datatracker.ietf.org/doc/draft-winter-opsawg-eap-metadata/

This is a config file for EAP-based networks. It includes schema  
elements / yang nodes to embed ToU, Logo, helpdesk contact details,  
operator friendly name etc.

An installer program that gets fed with such a config file can display  
the logo, ToU and similar before actually pushing the EAP type  
settings to the device; and from then on just be a normal 802.11i  
network.

There is already an Android app and a Linux installation script that  
consumes the file format; we are also currently working on a Windows  
version.

Apple's mobileconfig files also have a way to embed Terms of Use - but  
no logo.

The only remaining problem then is that the config needs to get to the  
device in the first place - which means in most cases that you need a  
captive portal which only allows to download the config for the "real"  
network.

Hotspot 2.0 was designed with that use case in mind, but for wired  
networks, you are a bit more on your own.

Greetings,

Stefan Winter

---

From: "Roscoe, Alexander" <[email-masked]>
Date: Fri, 9 Oct 2015 15:15:41 +0000

I really think we need to focus on upgrading the security of the user
during authentication. Security was echoed by many participants in Prague.
The two main issues are an unsecured physical link and the authorization
by MAC address.  I think Hotspot 2.0 and Passpoint can help solve both of
these issues. I think the role of a captive portal should be to shepherd
the user into upgrading their security during authentication.

I have just rolled out our mobile provisioning configuration via the
captive portal and it was a headache between both iOS and Andriod.  It
would be nice if we can come up with a standard on provisioning these
mobile configs during authentication.  The limited iOS captive portal mode
is a bit clunky during the process but it still works.  The recent version
of the captive portal browser in Android just made it difficult to install
provisioning configurations.

-- 
Alexander Roscoe
Comcast - Wireless Engineer
Phone  215.286.7283
Cell  215.609.2691

On 10/9/15, 10:58 AM, "[email-masked]"
<[email-masked]> wrote:

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