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

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

Date: Tue, 6 Oct 2015 12:26:09 -0700

Archived-at: <http://mailarchive.ietf.org/arch/msg/captive-portals/n5DwjxpTR9oZohf1WpoUSuk-EOo>

Cc: Michael Richardson <[email protected]>, "[email protected]" <[email protected]>, "Roscoe, Alexander" <[email protected]>

Delivered-to: [email protected]

Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oYamuKVh1/yhqwXS3ytCTgTvHFQL/+Gnpn91NbGV3hM=; b=EO7qeIAPQIGUN+lsgrrWZcP7eIRUaIS0mX62zw4uShTwFaiWuE4ECWlG9R6SEuSZYn itOYOLThLfz0J8W7Z3lcIO1jKt5qBx/WI0B678mWEpDyLWOGvK2uEH3qRU4V4t2u4eBd 0LOdEbG4bXbbTufFMMF+wLn+1hFU55iVhAXyhpKFIkYDTcZR5p5OfK9epmXka4K6nmfi iJkMxoJDzcFEmwfPzWuWIRicxBNbKMOqSr04sNV1z23bgWOi6eoRVhM1Y3Vjm0gX3vHE OVFBPH9YBZ5LdV4GusqiuYeEAF3d+fXNPlCVKDRdNHCdrmdJSp56W8XIyJDxvp9JV9Re ezTw==

In-reply-to: <[email protected]>

List-archive: <https://mailarchive.ietf.org/arch/browse/captive-portals/>

List-help: <mailto:[email protected]?subject=help>

List-id: Discussion of issues related to captive portals <captive-portals.ietf.org>

List-post: <mailto:[email protected]>

List-subscribe: <https://www.ietf.org/mailman/listinfo/captive-portals>, <mailto:[email protected]?subject=subscribe>

List-unsubscribe: <https://www.ietf.org/mailman/options/captive-portals>, <mailto:[email protected]?subject=unsubscribe>

References: <[email protected]om> <[email protected]> <[email protected]om> <[email protected]> <[email protected]> <[email protected]> <[email protected]om> <[email protected]> <[email protected]om> <[email protected]> <[email protected]om> <D23987EB.1133B%[email protected]> <[email protected]>

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 protected]> wrote:

On Oct 6, 2015, at 11:23 AM, Roscoe, Alexander <[email protected]> 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.

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