Subject: [OPSAWG] Looking for some feedback on a draft.

From: Warren Kumari <[email-masked]>
Date: Wed, 1 Oct 2014 17:21:07 -0400

<no hats>
Hi there all,

I have a draft that I'd like some review / feedback on.
It will likely be AD sponsored (it doesn't really fit in any working groups).

It is designed to help make the captive portal experience better^W less bad.
We've all experienced this -- you arrive at a hotel or coffee-shop.
You open your laptop and connect to the Hilton_Guest network (or
whatever) and then nothing happens...
You click refresh on your (in this day and age) https:// pages, and
either they just hang, or you get some unintelligible SSL error about
the certificate not matching the site you were trying to get to... or
you have a VPN / proxy, in which case *nothing* happens.
You kill the VPN, still nothing.
You curse a few times, then notice that DNS isn't working. After some
futzing (and more swearing) you disable your local validating
resolver, and update resolv.conf to use the hotel network.

Eventually you get a web page that tells you you can get to the
Internet for the low low price of $9.95 for 24hours. 3 hours later the
process repeats. After throwing your laptop on the floor and jumping
up and down you redo the captive portal dance and continue using the
'net.

Now, obviously the bestest possible outcome would be if there were no
captive portals, but, well, that ain't going to happen.... so, this
document lets DHCP / RA *tell* your machine where the CP is, so your
OS can make a connection as soon as you try access the Internet. Yup,
there are many more details, go read the draft...

http://tools.ietf.org/html/draft-wkumari-dhc-capport-05

W

This technique is complementary with the Wi-Fi Alliance: Hotspot 2.0 /
PassPoint "ASRA" - Additional Steps Required for Access idea...

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Joe Clarke <[email-masked]>
Date: Thu, 02 Oct 2014 13:29:54 -0400

> http://tools.ietf.org/html/draft-wkumari-dhc-capport-05

This sounds reasonable in principle, but how do you divorce the DHCP 
lease from the interactive desktop experience on certain platforms?  For 
example, on my FreeBSD laptop, a DHCP lease is obtained asynchronously 
before I even login to GDM/X.  How does my browser know that the CP has 
been provided via DHCP?  Will this require some fundamental change up 
the stack into all network aware applications?

Joe

---

From: Warren Kumari <[email-masked]>
Date: Thu, 2 Oct 2014 14:15:31 -0400

On Thu, Oct 2, 2014 at 1:29 PM, Joe Clarke <[email-masked]> wrote:
> This sounds reasonable in principle, but how do you divorce the DHCP lease
> from the interactive desktop experience on certain platforms?  For example,
> on my FreeBSD laptop, a DHCP lease is obtained asynchronously before I even
> login to GDM/X.  How does my browser know that the CP has been provided via
> DHCP?  Will this require some fundamental change up the stack into all
> network aware applications?

Yes, kinda. Not really changes up the stack, simply the operating
system, using some OS proprietary mechanism the fact that the machine
is behind the captive portal. We are explicitly *not* defining how
this gets exposed in the draft, it's simply not our place... but...

Once you login the OS could automagically start a browser instance
(with a separate cookie store, etc) connecting to the URI provided by
DHCP (Apple already does something similar to this -- MacOS and iOS
try "get" http://www.apple.com/library/test/success.html (e.g:
http://blog.erratasec.com/2010/09/apples-secret-wispr-request.html#.VC2U2ildUcs
)).

Or, when you manually start the browser / network application it could
ask the OS (possibly by reading something out of /proc, a sysctl, etc)
and discover that it needs to do "stuff".

How this gets done internally is entirely up to the OS vendor....

W

---

From: Joe Clarke <[email-masked]>
Date: Thu, 02 Oct 2014 16:13:30 -0400

> http://blog.erratasec.com/2010/09/apples-secret-wispr-request.html#.VC2U2ildUcs

Yeah, this would definitely put "burden" on the OS people.  In the case 
of FreeBSD, that would mean the ports developers as well so that DEs 
like GNOME, KDE, and Xfce do the right thing.  For those twm (or VTY) 
die-hards, this would be left up to scripting and other hacks.  I 
imagine stacks like ISC's would need to be taught to write out CP info 
on a per-OS basis.

> How this gets done internally is entirely up to the OS vendor....

Right, but in my case Firefox is an application completely independent 
from FreeBSD.  _It_ would need some knowledge of how FreeBSD exposes the 
CP info obtained via DHCP.  So from an application standpoint (layer 8, 
9, ...) there would need to be some per-OS knowledge.

 From a security standpoint, I like the idea.  And I get how 
implementation is out of scope, though I know you're considering it. 
This was just my thoughts coming from an "alternative" OS that might add 
some roadblocks in terms of adoption, and require a longer life to 
things like TCP interception.

Joe

---

From: Warren Kumari <[email-masked]>
Date: Fri, 3 Oct 2014 13:53:14 -0400

On Thu, Oct 2, 2014 at 4:13 PM, Joe Clarke <[email-masked]> wrote:
>>> lease
> Yeah, this would definitely put "burden" on the OS people.  In the case of
> FreeBSD, that would mean the ports developers as well so that DEs like
> GNOME, KDE, and Xfce do the right thing.  For those twm (or VTY) die-hards,
> this would be left up to scripting and other hacks.  I imagine stacks like
> ISC's would need to be taught to write out CP info on a per-OS basis.
>
>>
> Right, but in my case Firefox is an application completely independent from
> FreeBSD.  _It_ would need some knowledge of how FreeBSD exposes the CP info
> obtained via DHCP.  So from an application standpoint (layer 8, 9, ...)
> there would need to be some per-OS knowledge.
>
> From a security standpoint, I like the idea.

Thank you!

>  And I get how implementation
> is out of scope, though I know you're considering it. This was just my
> thoughts coming from an "alternative" OS that might add some roadblocks in
> terms of adoption, and require a longer life to things like TCP
> interception.
>

Yah. Realistically the DNS / TCP interception stuff will be around for
many years (10+ as a wild guestimate) -- however, if you are using a
device that understands this, you can start getting benefits sooner...

W

---

From: Robert Story <[email-masked]>
Date: Fri, 10 Oct 2014 15:40:54 -0400

On Wed, 1 Oct 2014 17:21:07 -0400 Warren wrote:
WK> Eventually you get a web page that tells you you can get to the
WK> Internet for the low low price of $9.95 for 24hours.

Is there something existing for this? On my android phone I can connect to
open networks, and often it automatically opens my browser to a portal
login page. But I have no idea at what level this happens...

Robert

-- 
Senior Software Engineer @ Parsons

---

From: joel jaeggli <[email-masked]>
Date: Fri, 10 Oct 2014 13:09:41 -0700

> login page. But I have no idea at what level this happens...

IOS tests a url they know they should be able to reach over the
internet. if they get a redirect or a different page then expected
they'll treat it as a captive portal.

that's a fairly adhoc method. the fact  that it works as often as it
does is itself fairly remarkable.

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

---

From: "Dale W. Carder" <[email-masked]>
Date: Fri, 10 Oct 2014 16:05:01 -0500

I have a few questions / comments:

- IPv6 has DHCP also.  Can that be used instead of RA?  (I am not looking
to start a war, I just want to understand why you picked RA).  This
might be an issue because typically RA's would be sent from routers that
are not necessarily the captive portal.  A dhcp option could be more
selectively/dynamically given to clients and could support both captive 
portal and non-captive portal users on the same L3 segment.  Another 
example use case of this would be for things pre-registered with the 
portal, no need to worry them futher.

- Should it be pointed out that this would only happen after 802.11u,
802.11X, or similar L2 things have already failed to auth?

- You note that you want embedded address literals because the user may
have broken DNS settings for that network.  If the dhcp server gave you 
dns settings which you knowingly ignored, then it is a mis-configuration.
The same thing would happen if you statically configured a default
router while ignoring what was recieved in RA or DHCP.  In other words
on captive portal networks, I think a more robust interpretation would
be that the DNS server supplied from the network is not a hint, it is 
mandatory at least until registration.

- What happens in the following dual-stack scenario:
dhcpv4 captive-portal option not set
dhcpv6 or RA captive-portal option set

Does that mean the client only has to do portal registration for v4?  I
think you can guess at all the permutations when dual-stacked.  It gets
worse for RA because some RA's could have it set but not others.  Do we
say that this is a misconfiguration?  Or do we say if the option is set
via *any* means, then assume it is set for them all? 

- What about the bad guy who sets up a rougue dhcp server with the
option set in order to extract usernames/passwords/money?  There was a
similar topic that came up (in sunset4, I think) about a hypothetical
dhcp option to hint to clients not to use their v4 stack.  The most
robust thing for a client to do would be to ignore that option due to
the possibility of bad guys.  That may also mean the most robust thing
for a client to do is treat the captive-portal option only as a hint and
not necessarily hold everything up because of it.

Dale

---

From: Warren Kumari <[email-masked]>
Date: Sat, 11 Oct 2014 18:53:36 -0400

On Fri, Oct 10, 2014 at 5:05 PM, Dale W. Carder <[email-masked]> wrote:
> to start a war, I just want to understand why you picked RA).

I didn't - I picked DHCPv4 and DHCPv6, and a bunch of v6 folk shouted
at me for doing it wrong, so I added RA and dropped DHCPv6. This made
some other folk mad, so I tried both, and provided some arbitrary
sorting rules. This resulted in both sides being unhappy, so I went
with the tactic of keeping the scarier group (Lorenzo and Erik) happy.

I have the DHCPv6 text kicking around in an SVN somewhere, happy to
put that back if that is what people want...

>  This

Well, it *could* happen after -- I've seen some networks that make you
*first* join a WPA network, and then still pop up a captive portal
(the WPA is to keep folk off the network, and the CP it to make them
agree not to do anything naughty with it).
But, I think it might be worth mentioning *something* about some
networks that have a "secured" network (no CP) and a "guest" network
(with a CP) -- do you happen to have any suggested text?

> have broken DNS settings for that network.

Nope, I guess that this text was not clear -- if the captive portal
allows DNS access (either with it's DNS servers, or using other DNS
servers (like 8.8.8.8), people can (and will) use DNS tunneling
(http://dnstunnel.de/) to bypass the CP. Especially if DPRIVE takes
off, captive portals will have a hard time filtering these...

I'll try clean this up to be clearer...

> If the dhcp server gave you

Or you simply don't trust the CP to not lie or spy on your DNS or ....

> Does that mean the client only has to do portal registration for v4?

Yes!
No!
I don't know!

I *think* that machines should only need to do a single captive portal
interaction for *all* protocols -- AFAIK, most captive portals
actually base their rules on MAC address.

>  I

I *think* so. But, I'm happy to:
A: hear other options and
B: even happier to accept text.

> option set in order to extract usernames/passwords/money?

I believe that if a bad guy can setup a rogue DHCP server he has
already won -- he can just as easily send DHCP responses with himself
as a default gateway, and then intercept, pop up a captive portal
page, etc...

> There was a

I think that it is safer to hold everything up -- if the DHCP response
*is* forged and contains a "bad" CP option it probably also contained
a bad gateway, dns server, etc. In that case, holding everything up
and running away is best, allowing the connection to the CP is
probably second best the user *might* notice that the attacker
misspelt Starbooks, and the worst is to shuffle traffic through the
(supplied) gateway...

Anyway, thank you very much for your feedback and review, more than
happy to chat more about this, etc.

W