Subject: [Captive-portals] Comments on draft-nottingham-capport-problem-00

From: "Livingood, Jason" <[email-masked]>
Date: Thu, 3 Mar 2016 00:16:27 +0000

Good document overall. Some comments/suggestions to consider for a 01
update. 

2.0, consider extending (IN CAPS):
³...before allowing broader (but not necessarily complete) Internet
access, OR FOR OTHER PURPOSES.²

2.0, consider adding techniques to include HTML injection, Internet
Content Adaptation Protocol (RFC 3507), and the method described in RFC
6108.

2.1, Information or Notifications, some possible additional examples:
security alerts, critical service information, account status, usage status

3.0, consider adding:
HTML injection, such as methods using ICAP, which runs counter to the
preferences of some users.

3.0, Feel free to take a look at the text in Section 12 of RFC 6108 and
use some of that text. You got the gist of it in the Non-Browser Clients
sub-section though (https://tools.ietf.org/html/rfc6108#section-12)

Regards
Jason

---

From: Martin Thomson <[email-masked]>
Date: Thu, 3 Mar 2016 11:24:41 +1100

> sub-section though (https://tools.ietf.org/html/rfc6108#section-12)

This raises an interesting point about internet dot org by facebook.
I wonder if there are any lessons to be learned from that as well.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 3 Mar 2016 13:02:11 +1100

Hi Jason, 

Thanks for that, I've made some edits; see:
  https://github.com/mnot/I-D/commit/950dcd04dfbb

Regarding notifications, I think we should discuss whether it's useful to consider them as 'captive portals' or not. The techniques are similar in many cases, but there are some important differences.

Cheers,

> On 3 Mar 2016, at 11:16 AM, Livingood, Jason <[email-masked]> wrote:
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Martin Thomson <[email-masked]>
Date: Thu, 3 Mar 2016 17:37:36 +1100

> Regarding notifications, I think we should discuss whether it's useful to consider them as 'captive portals' or not. The techniques are similar in many cases, but there are some important differenc…

I caution that this might be a case where we have to watch scope.  It
might be good to understand the methods and reasons, but those
differences could lead us down a rathole.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 3 Mar 2016 17:38:14 +1100

> On 3 Mar 2016, at 5:37 PM, Martin Thomson <[email-masked]> wrote:
> 

+1

---

From: "Livingood, Jason" <[email-masked]>
Date: Thu, 3 Mar 2016 13:24:35 +0000

>> Regarding notifications, I think we should discuss whether it's useful
>>to consider them as 'captive portals' or not. The techniques are similar
>>in many cases, but there are some important differences.
>

Fair concern. But we may not want the WG to be overly exclusive at this
early stage as to future implementations. I say that especially since at
least this operator would love to find better and more standardized
methods to do notifications using output from this WG that may fall into a
grey area between a captive portal and semi-captive portal (or however we
choose to label it) - it addition to improving Œclassic¹ captive portals
as defined here.

Jason

---

From: Dave Dolson <[email-masked]>
Date: Mon, 7 Mar 2016 15:08:27 +0000

Regarding non-browser clients, even non-HTTP clients, and considering
this is the IETF, it seems reasonable to find an IP-layer solution vs. 
an HTTP-layer solution.

E.g., a new ICMP/ICMP6 error code to indicate the host is walled, with a pointer
to the method to authenticate in the payload.
This could be an extension to "Network Unreachable", or a new code.

ICMP messages are handled by the O/S, and could trigger an authentication work-flow
appropriate to the device, whether it be a human-interface device like a tablet
or a head-less IOT device.

E.g., suppose the a VoIP phone becomes walled during a call. Outgoing packets
are answered with an ICMP message; the O/S immediately performs the authentication
using previously-provided credentials, and the call continues shortly thereafter.
If the credentials fail, the user can be presented with a  window or browser.

The ICMP payload would be a standard format, and could have security features
to avoid spoofing.

I guess I'm jumping ahead of the problem statement, but I think the
"Non-Browser Clients" issue could be changed to "Non-HTTP Clients",
providing a huge win.

-Dave

-----Original Message-----
From: Captive-portals [mailto:[email-masked]] On Behalf Of Martin Thomson
Sent: Wednesday, March 02, 2016 7:25 PM
To: Livingood, Jason
Cc: Mark Nottingham; [email-masked]
Subject: Re: [Captive-portals] Comments on draft-nottingham-capport-problem-00

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

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 7 Mar 2016 15:38:34 +0000

>this is the IETF, it seems reasonable to find an IP-layer solution vs.

+1 to that!

---

From: Paul Ebersman <[email-masked]>
Date: Mon, 07 Mar 2016 10:54:23 -0500

ddolson> Regarding non-browser clients, even non-HTTP clients, and
ddolson> considering this is the IETF, it seems reasonable to find an
ddolson> IP-layer solution vs. an HTTP-layer solution.

Indeed... All sorts of phone apps don't use HTTP but need to tickle the
reaction.

---

From: David Bird <[email-masked]>
Date: Mon, 7 Mar 2016 09:00:32 -0800

+1 for an ICMP solution ...
https://tools.ietf.org/html/draft-wkumari-capport-icmp-unreach-00

---

From: David Bird <[email-masked]>
Date: Mon, 7 Mar 2016 09:04:55 -0800

Sorry, link was to wrong version:
https://tools.ietf.org/html/draft-wkumari-capport-icmp-unreach-01

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 8 Mar 2016 12:24:27 +1100

> this is the IETF, it seems reasonable to find an IP-layer solution vs. 

Making the presence of a CP clear to non-HTTP clients seems like a good thing. Doing much more than that (e.g., presenting something to the user, getting their credentials) is less attractive.

Cheers,

---

From: "John Levine" <[email-masked]>
Date: 8 Mar 2016 12:49:37 -0000

>Indeed... All sorts of phone apps don't use HTTP but need to tickle the

Even worse, they do use HTTP but expect an answer from their own server
and strange things happen when they get the portal's page instead.

R's,
John

---

From: David Farmer <[email-masked]>
Date: Tue, 8 Mar 2016 09:37:08 -0600

While at the same time if we want people to actually use it, a non-HTTP 
solution can't become a trivially easy off-path attack vector or any of 
a number of other security problems either.

I think a non-HTTP solution is critically important, but it's equally 
important to get the security right for all of this, HTTP(S) based or 
not.  This is going to fundamentally be hard to get right, if it was 
easy we would have dealt with this long ago, but now it time to work 
through this and get it right.

Thanks

-- 
================================================
David Farmer               Email: [email-masked]
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================