Subject: Re: [Captive-portals] A new draft / idea - draft-wkumari-capport-icmp-unreach

From: David Bird <[email-masked]>
Date: Mon, 5 Oct 2015 18:17:06 -0700

Hoping to summarize this thread;

- ICMP shouldn't carry and "configuration", but as notification only, it is
no worse than traditional ICMP; draft update, thanks Warren.

- There is a concern in linking DHCP functions and captive portal. Perhaps,
if the DHCP setting is always static (e.g. it is not used to indicate
explicitly that certain devices are subject to CP and others, who might
have "auto-authenticated", aren't), it becomes just configuration and not
integration.

- There are concerns that DHCP isn't the only way to obtain network
configuration... a couple suggestions:

    -- In a different thread, .well-known URIs were suggested. The DHCP
parameters could be IP addresses instead of URI (hmm, does the current
draft really mean URL?) and the URI part is a .well-known

   -- In the absence of the DHCP parameter, the default gateway is used.

Keep in mind, this CP-IP/.well-known/cp-redirect is the "entry" point to
the CP. It is expected that the application answering will have the
necessary information (like client MAC address, IP address, etc) to format
the CP URL that otherwise would have been in a 302 redirect. so, the CP web
application can, and should, be using HTTPS.

What capport-icmp brings is a means of CP notification - a more specific
replacement for traditional Dest. Unreach. or TCP Reset, or simply dropped
packets. Oh, and also a whole lot better than hijacking HTTPS :)

David

See you in Yokohama!

On Tue, May 5, 2015 at 8:46 AM, Nicolas Mailhot <[email-masked]
> wrote:

>
> Le Ven 1 mai 2015 13:42, Yaron Sheffer a écrit :
> > As a user, I have never seen a case where the captive portal is not on
> > the same link as the client device, and never seen a case where an IP is
> > obtained using a non-DHCP mechanism when in a CP setting. Can you give
> > some concrete examples?
>
> user   ]
> (local ]---[ Corp Network ]
> dhcp ) ]     |
>              |   [ Corp Datacenter 1     ]   [ www gateway 1 ]
>              |---[ with internal webapps ]---[ with captive  ]-|
>              |   [ in direct access      ]   [ portal        ] |--[ W ]
>              |                                                    [ W ]
>              |   [ Corp Datacenter 2     ]   [ www gateway 2 ] |--[ W ]
>              |---[ with internal webapps ]---[ with captive  ]-|
>                  [ in direct access      ]   [ portal        ]
>                           |
>                  [ Permanent VPN tunnel ]
>                           |
>                  [ Partner datacenter   ]
>                  [ and internal webapps ]
>                  [ in direct access     ]
>
> Two datacenters and www links since that's the minimum for business
> continuity, can be more easily. Captive portal can and is dedicated to www
> http(s) access not other firewalled protocols
>
> If such configurations didn't exist there would be no need for pac files.
>
> --
> Nicolas Mailhot
>
> _______________________________________________
> Captive-portals mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/captive-portals
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 06 Oct 2015 08:53:30 -0400

David Bird <[email-masked]> wrote:
    > necessary information (like client MAC address, IP address, etc) to
    > format the CP URL that otherwise would have been in a 302 redirect. so,
    > the CP web application can, and should, be using HTTPS.

I don't know how it can use HTTPS given current certificate options.

The only identity that the CP has that the client can verify is it's MAC
address, and that's not currently an option for certificates. (I've argued
that it should be: iLOMs and other (home) appliances have the same problem)

After the 302 redirect, I can see how it could be a redirect *to* a https URL.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: David Bird <[email-masked]>
Date: Tue, 6 Oct 2015 09:19:58 -0700

To clarify, there is a CP access controller (let's call this CP-NAS) and a
CP web application (and this CP-WEB). The DHCP option could return the IP
address of the CP-NAS (if not the same as the default gateway). We can then
define a .well-known URL, such as http://CP-NAS/.well-known/capport-redirect,
which the client can use to learn the (possibly device and session
specific) URL to the CP-WEB application. The CP-NAS URL is always HTTP and
only does a 302 redirect to the CP-WEB application. This provides a
convenient and standard way for the client to pick-up the CP-WEB URL (with
all necessary query string parameters added by the CP-NAS) without having
to "guess" a URL outside of the walled garden or wait for the user to visit
a HTTP site. The CP-WEB URL can, and should, be HTTPS if handling any user
data (though, perhaps not a MUST as a Terms of Service only wouldn't
necessarily require https).

* Note: CoovaChilli already has this type of internal URL
(http://chilli-ip:uam-port/prelogin).

I'm not sure it belongs in RFC, but ideally, I'd like to see Clients NOT
use a limited (sandbox) browser when a CP-WEB is using HTTPS. TLS should be
providing all the necessary security and Clients using sandboxed browsers
for CP interaction is WHY hotspot providers circumvent OS CP detection. (I
actually don't see much real benefit in a sandbox browser for HTTP either.
A "bad" network could just also whitelist CP detection URLs, or even just
offer pure Open WiFi, to prevent the sandbox browser from being used.
However, if vendors do still use a sandboxed browser for HTTP CP-WEB, it
will just encourage networks to use HTTPS, which is probably a good thing.)

---

From: Michael Richardson <[email-masked]>
Date: Tue, 06 Oct 2015 13:07:51 -0400

David Bird <[email-masked]> wrote:
    > To clarify, there is a CP access controller (let's call this CP-NAS)
    > and a CP web application (and this CP-WEB). The DHCP option could
    > return the IP address of the CP-NAS (if not the same as the default
    > gateway). We can then define a .well-known URL, such as
    > http://CP-NAS/.well-known/capport-redirect, which the client can use to

so, in this context, "CP-NAS" would be an IP address literal?
(I ask, because there are lots of portal vendors who think that DNS search
strings work, and might use a literal "cp-nas"...)

    > learn the (possibly device and session specific) URL to the CP-WEB
    > application. The CP-NAS URL is always HTTP and only does a 302 redirect
    > to the CP-WEB application. This provides a convenient and standard way
    > for the client to pick-up the CP-WEB URL (with all necessary query
    > string parameters added by the CP-NAS) without having to "guess" a URL
    > outside of the walled garden or wait for the user to visit a HTTP
    > site. The CP-WEB URL can, and should, be HTTPS if handling any user

good.
It does require https, because the browser and end user have to be sure that
they reached the right web site.  

    > (http://chilli-ip:uam-port/prelogin).

Is CoovaChilli still alive as a project, btw?  It was unclear to me last time
I looked.

    > I'm not sure it belongs in RFC, but ideally, I'd like to see Clients
    > NOT use a limited (sandbox) browser when a CP-WEB is using HTTPS.

The logic is that you don't give strangers your cookies, or your
HTTP Basic Authentication headers.

With HTTP, we have no control over what name maps to what server (because
HTTP is trivially hijackable), so one would send any cookies one might have
for that FQDN.

---

From: David Bird <[email-masked]>
Date: Tue, 6 Oct 2015 10:52:01 -0700

> strings work, and might use a literal "cp-nas"...)
Yes, IP address literal.

> they reached the right web site.
Though, having a SSL cert doesn't necessarily mean it's the "right"
website. I don't think we have to require HTTPS in all situations, but I
could be convinced otherwise.

> Is CoovaChilli still alive as a project, btw?  It was unclear to me last
Yes, CoovaChilli is still active... It recently relocated to github and is
supported by a (smallish, but active) community of developers, including
myself.

> HTTP is trivially hijackable), so one would send any cookies one might have
I don't disagree... My point is simply that a network, Open or otherwise,
without CP (or with CP that whitelisted the OS CP detection end-points)
render this sandbox browser feature useless. Moreover, why would a Client
STOP using the sandbox browser after "authentication" (does the client all
the sudden trust this (probably open) public access network more now?).

David

---

From: "Roscoe, Alexander" <[email-masked]>
Date: Tue, 6 Oct 2015 18:23:29 +0000

I am really a big fan of having the ability to pass FQDN as a DHCP option.  I assume all un-authed users will have access to DNS.  There are some edge case scenarios will this will fail, especially in mobility situations where a roams between 2 of the same SSIDs that have a different DHCP server and cache. I think an ICMP reply would offer another mechanism to determine the clients state.

I do not think HTTPS should be a requirement, this should be left to the discretion of the the hotspot provider.  Many hotspots, especially in the U.S. require users at a minimal check a terms of service box to get internet access.  An application like this would not need to be secure as there is no sensitive information being passed.

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

From: David Bird <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, October 6, 2015 at 1:52 PM
To: Michael Richardson <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Captive-portals] A new draft / idea - draft-wkumari-capport-icmp-unreach

On Tue, Oct 6, 2015 at 10:07 AM, Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:

Yes, IP address literal.

good.

Though, having a SSL cert doesn't necessarily mean it's the "right" website. I don't think we have to require HTTPS in all situations, but I could be convinced otherwise.

Yes, CoovaChilli is still active... It recently relocated to github and is supported by a (smallish, but active) community of developers, including myself.

I don't disagree... My point is simply that a network, Open or otherwise, without CP (or with CP that whitelisted the OS CP detection end-points) render this sandbox browser feature useless. Moreover, why would a Client STOP using the sandbox browser after "authentication" (does the client all the sudden trust this (probably open) public access network more now?).

David

---

From: "Linss, Peter" <[email-masked]>
Date: Tue, 6 Oct 2015 19:07:03 +0000

> I do not think HTTPS should be a requirement, this should be left to the discretion of the the hotspot provider.  Many hotspots, especially in the U.S. require users at a minimal check a terms of s…

I strongly disagree with this sentiment. These days HTTPS should be the default for all new features, and HTTP only used when there is a technical requirement preventing the use of HTTPS. We want to make the net secure, not add more attack surface.

There have already been reported incidents where the attacker joins a public wifi and hijacks DHCP. The user should have some assurance that the captive portal they're entering their credit card info into is the right one.

Peter

---

From: David Bird <[email-masked]>
Date: Tue, 6 Oct 2015 12:09:38 -0700

Is the suggestion of having a FQDN in the DHCP parameter for the purpose of
"matching" against a HTTPS hostname? I can see the value of that, but that
value only comes when you require the well known CP-NAS URL to be
https://fqdn/...  The CP-NAS interface _could_ be shared among networks,
but more likely it means you need a cert per CP-NAS (which can mean per
AP/hotspot). Using a single cert for all NAS would probably violate your
cert agreement, and storing a valid cert on the NAS is a security risk
itself, in some situations.

In the mobility case mentioned, if the client moved to a different network
segment and DHCP server, wouldn't his lease be invalid? Can you also
elaborate on the ICMP reply suggestion?

David

On Tue, Oct 6, 2015 at 11:23 AM, Roscoe, Alexander <
[email-masked]> wrote:

> I am really a big fan of having the ability to pass FQDN as a DHCP
> option.  I assume all un-authed users will have access to DNS.  There are
> some edge case scenarios will this will fail, especially in mobility
> situations where a roams between 2 of the same SSIDs that have a different
> DHCP server and cache. I think an ICMP reply would offer another mechanism
> to determine the clients state.
>
> I do not think HTTPS should be a requirement, this should be left to the
> discretion of the the hotspot provider.  Many hotspots, especially in the
> U.S. require users at a minimal check a terms of service box to get
> internet access.  An application like this would not need to be secure as
> there is no sensitive information being passed.
>
>
> --
> Alexander Roscoe
> Comcast – Xfinity Wifi - Wireless Engineer
> Phone – 215.286.7283
> Cell – 215.609.2691
>
> From: David Bird <[email-masked]>
> To: Michael Richardson <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> On Tue, Oct 6, 2015 at 10:07 AM, Michael Richardson <[email-masked]
> > wrote:
>

---

From: "Roscoe, Alexander" <[email-masked]>
Date: Tue, 6 Oct 2015 19:25:11 +0000

I was making the case specifically where a user does not need to enter sensitive information. HTTPS should always be used in that case of credentials and payment info..
--
Alexander Roscoe
Comcast - Wireless Engineer
Phone - 215.286.7283
Cell - 215.609.2691

From: "Linss, Peter" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, October 6, 2015 at 3:07 PM
To: Alex Roscoe <[email-masked]<mailto:[email-masked]>>
Cc: David Bird <[email-masked]<mailto:[email-masked]>>, Michael Richardson <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Captive-portals] A new draft / idea - draft-wkumari-capport-icmp-unreach

On Oct 6, 2015, at 11:23 AM, Roscoe, Alexander <[email-masked]<mailto:[email-masked]>> wrote:

Peter

---

From: David Bird <[email-masked]>
Date: Tue, 6 Oct 2015 12:26:09 -0700

I am not sure requiring HTTPS here really addresses the attack surface. If
someone hijacked DHCP, they could point the user to their own HTTPS site
ready to take payment.

I don't think anyone disagrees that when taking sensitive information from
users, it MUST be using HTTPS (and the user should, though they often
don't, check the hostname is one they "trust" giving money/info to). This
isn't, however, a problem limited to CP networks, nor one we need to solve,
imho.

The risk of requiring certs for the CP-NAS interface is that WISPs will
probably just use self-signed certs and make the user suffer the browser
warnings... (Or, worse, they will not use the spec and everyone has a
Legacy experience).

On Tue, Oct 6, 2015 at 12:07 PM, Linss, Peter <[email-masked]> wrote:

>
> On Oct 6, 2015, at 11:23 AM, Roscoe, Alexander <
> I strongly disagree with this sentiment. These days HTTPS should be the
> default for all new features, and HTTP only used when there is a technical
> requirement preventing the use of HTTPS. We want to make the net secure,
> not add more attack surface.
>
> There have already been reported incidents where the attacker joins a
> public wifi and hijacks DHCP. The user should have some assurance that the
> captive portal they're entering their credit card info into is the right
> one.
>
> Peter
>

---

From: "Roscoe, Alexander" <[email-masked]>
Date: Tue, 6 Oct 2015 19:52:49 +0000

I like the idea of an FQDN because certs and as well as load balancing. My current portal redirect is delivered by an HTTP 302 redirect from the gateway and then immediately upgrades to HTTPS. The gateway and AAA server act as the controller but they all deliver the same FQDN so I am able and able to terminate the cert at the load balancer.  VIPS could be used as well but FQDNs allow for more flexibility.

For mobility, I have many Aps next to each other that can receive different treatments like free wifi or paid wifi.  . When a client jumps between SSIDs, it assumes its using the same IP and does not do a DHCP discovery.  There are devices out there in the wild that need to wait until the lease expires to get a new IP even if connectivity is poor.  I think having the ability to notify the user need to be authenticated as its a new network.
--
Alexander Roscoe
Comcast - Wireless Engineer
Phone – 215.286.7283
Cell – 215.609.2691

From: David Bird <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, October 6, 2015 at 3:09 PM
To: Alex Roscoe <[email-masked]<mailto:[email-masked]>>
Cc: Michael Richardson <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Captive-portals] A new draft / idea - draft-wkumari-capport-icmp-unreach

Is the suggestion of having a FQDN in the DHCP parameter for the purpose of "matching" against a HTTPS hostname? I can see the value of that, but that value only comes when you require the well known CP-NAS URL to be https://fqdn/...  The CP-NAS interface _could_ be shared among networks, but more likely it means you need a cert per CP-NAS (which can mean per AP/hotspot). Using a single cert for all NAS would probably violate your cert agreement, and storing a valid cert on the NAS is a security risk itself, in some situations.

In the mobility case mentioned, if the client moved to a different network segment and DHCP server, wouldn't his lease be invalid? Can you also elaborate on the ICMP reply suggestion?

David

On Tue, Oct 6, 2015 at 11:23 AM, Roscoe, Alexander <[email-masked]<mailto:[email-masked]>> wrote:
I am really a big fan of having the ability to pass FQDN as a DHCP option.  I assume all un-authed users will have access to DNS.  There are some edge case scenarios will this will fail, especially in mobility situations where a roams between 2 of the same SSIDs that have a different DHCP server and cache. I think an ICMP reply would offer another mechanism to determine the clients state.

--
Alexander Roscoe
Comcast – Xfinity Wifi - Wireless Engineer
Phone – 215.286.7283<tel:215.286.7283>
Cell – 215.609.2691<tel:215.609.2691>

Yes, IP address literal.

good.

David

---

From: David Bird <[email-masked]>
Date: Tue, 6 Oct 2015 13:09:06 -0700

We could allow for multiple CP DHCP parameters or have the DHCP server
round-robin the assignment. I'm not sure FQDN helps with certs in your
example, since the CP-NAS would be your gateway and once upgraded to https
(using your FQDN), you are still DNS load-balancing to your CP-WEB
applications.

Indeed, in your mobility example, capport-icmp will help by indicating CP
interaction is required (if that is the case).

On Tue, Oct 6, 2015 at 12:52 PM, Roscoe, Alexander <
[email-masked]> wrote:

> I like the idea of an FQDN because certs and as well as load balancing. My
> current portal redirect is delivered by an HTTP 302 redirect from the
> gateway and then immediately upgrades to HTTPS. The gateway and AAA server
> act as the controller but they all deliver the same FQDN so I am able and
> able to terminate the cert at the load balancer.  VIPS could be used as
> well but FQDNs allow for more flexibility.
>
> For mobility, I have many Aps next to each other that can receive
> different treatments like free wifi or paid wifi.  . When a client jumps
> between SSIDs, it assumes its using the same IP and does not do a DHCP
> discovery.  There are devices out there in the wild that need to wait until
> the lease expires to get a new IP even if connectivity is poor.  I think
> having the ability to notify the user need to be authenticated as its a new
> network.
> --
> Alexander Roscoe
> To: Alex Roscoe <[email-masked]>
> Cc: Michael Richardson <[email-masked]>, "[email-masked]"
> <[email-masked]>
>
> Is the suggestion of having a FQDN in the DHCP parameter for the purpose
> of "matching" against a HTTPS hostname? I can see the value of that, but
> that value only comes when you require the well known CP-NAS URL to be
>> On Tue, Oct 6, 2015 at 10:07 AM, Michael Richardson <
>> [email-masked]> wrote:
>>
>> Yes, CoovaChilli is still active... It recently relocated to github and
>> is supported by a (smallish, but active) community of developers, including
>> myself.
>>
>>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 06 Oct 2015 16:45:17 -0400

David Bird <[email-masked]> wrote:
    > website.  I don't think we have to require HTTPS in all situations, but
    > I could be convinced otherwise.

Absent the problem of the web-CAs being corrupted, HTTPS means that the name
in the browser location bar, and the web site reached are the same.
The browser makes decisions about what to send based upon that data, so
that's why it matters.

HTTP can't promise that.

    > I don't disagree... My point is simply that a network, Open or
    > otherwise, without CP (or with CP that whitelisted the OS CP detection
    > end-points) render this sandbox browser feature useless. Moreover, why
    > would a Client STOP using the sandbox browser after "authentication"
    > (does the client all the sudden trust this (probably open) public
    > access network more now?).

Using a sandboxed browsers for HTTP sites makes a lot of sense to me :-)

---

From: Michael Richardson <[email-masked]>
Date: Tue, 06 Oct 2015 16:49:39 -0400

David Bird <[email-masked]> wrote:
    > probably just use self-signed certs and make the user suffer the
    > browser warnings... (Or, worse, they will not use the spec and everyone
    > has a Legacy experience).

I think that the bypass for self-signed certs will be further buried in
browsers, and so WISPs that do that will simply have either no customers,
or massive calls to the support desk.

I'm happy with either result, but I still would like a new SubjectAltName for
appliances, yes, including home routers. (The Home CPE that has no uplink
configured is a defacto captive portal)

---

From: David Bird <[email-masked]>
Date: Tue, 6 Oct 2015 16:33:44 -0700

> in the browser location bar, and the web site reached are the same.

Yes, of course. But, you still don't know it is the 'right' site,
necessarily.

> The browser makes decisions about what to send based upon that data, so
The browser (and hopefully the user!) make decisions based on the domain
name and HTTPS status. A user, obviously, should NOT enter information into
a site, even if using https, if the user doesn't trust that domain.
(nothing here is CP specific).

That said, I see the potential value of having a FQDN in DHCP that can be
matched up against the HTTPS CP-WEB application. But, in my suggested
changes, the DHCP option isn't telling the client the CP-WEB location. It
is instead telling the client the CP-NAS location (which isn't https).
 [Having DHCP give out URLs to CP-WEB directly will require that DHCP be
part of the NAS given that the CP-WEB URLs are typically device/session
specific in the query string parameters].

> Using a sandboxed browsers for HTTP sites makes a lot of sense to me :-)
I think it makes sense, but not because it detected a CP, rather because
the user has classified the location as "Public access" (vs. Home or Work,
etc). It doesn't make sense to me that a Client will be more suspicious of
a CP network vs. any Open SSID w/o CP or that the Client starts to "trust"
a (open) network only because it passed the CP. I'd be happy if Clients
treated ALL Open SSIDs automatically as "Public access" and always used a
sandboxed browser for HTTP, even after interacting with a CP.

David