



Network Working Group                                      M. Nottingham
Internet-Draft                                             April 4, 2016
Intended status: Informational
Expires: October 6, 2016


                   Captive Portals Problem Statement
                  draft-nottingham-capport-problem-01

Abstract

   This draft attempts to establish a problem statement for "Captive
   Portals", in order to inform discussions of improving their
   operation.

Note to Readers

   The issues list for this draft can be found at
   https://github.com/mnot/I-D/labels/capport-problem .

   The most recent (often, unpublished) draft is at
   https://mnot.github.io/I-D/capport-problem/ .

   Recent changes are listed at https://github.com/mnot/I-D/commits/gh-
   pages/capport-problem .

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on October 6, 2016.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Nottingham               Expires October 6, 2016                [Page 1]

Internet-Draft          CAPPORT Problem Statement             April 2016


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Notational Conventions  . . . . . . . . . . . . . . . . .   2
   2.  Defining Captive Portals and Networks . . . . . . . . . . . .   2
     2.1.  Why Captive Portals Are Used  . . . . . . . . . . . . . .   3
   3.  Issues Caused by Captive Portals  . . . . . . . . . . . . . .   3
   4.  Issues Caused by Captive Portal Detection . . . . . . . . . .   5
     4.1.  Issues Caused by Defeating Captive Portal Detection . . .   5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     6.2.  URIs  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   This draft attempts to establish a problem statement for "Captive
   Portals", in order to inform discussions of improving their
   operation.

1.1.  Notational Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.  Defining Captive Portals and Networks

   A "_captive network_" is a network that employs a captive portal for
   a variety of purposes; see Section 2.1.  A "_captive portal_" is a
   Web site that captive networks direct users to.

   This is achieved by directing requests for "normal" Web access to the
   captive portal, through variety of techniques, including DNS
   poisoning, TCP interception, HTTP response modification and/or HTTP
   redirection.



Nottingham               Expires October 6, 2016                [Page 2]

Internet-Draft          CAPPORT Problem Statement             April 2016


   Once the captive network's goals are met, the network "remembers"
   that the user is allowed network access, usually by MAC address,
   although there is a significant amount of variance between
   implementations.

   Over time, operating systems have developed "_captive portal
   detection_" processes to discover captive networks, and to assist
   users through the process of obtaining full network access.  They
   often involve specialised "_captive portal browsers_" which only
   allow the captive portal to use a subset of the full capabilities of
   a Web browser, and have a different user experience.

2.1.  Why Captive Portals Are Used

   Captive portals are deployed in a variety of situations, but the most
   common motivations are:

   o  *Authentication* - Obtaining user credentials before authorising
      network access

   o  *Payment* - Obtaining payment for using the network.

   o  *Information* - Presenting information to the user.  This might
      include displaying legal notices, details about the network
      provider and/or its location, advertisements, policies, etc., and
      obtaining user consent.

   o  *Notifications* - Some networks use the same mechanisms as captive
      portals to notify users of account status, network downtime,
      emergency alerts, etc.  See [RFC6108] for an example of one way
      this is done.

   In all of these cases, using a Web browser is attractive, because it
   gives the network the ability to tailor the user's interface and
   experience, as well as the ability to integrate third-party payment,
   advertising, authentication and other services.

3.  Issues Caused by Captive Portals

   When a network imposes a captive portal, it can cause a variety of
   issues, both for applications and end users.

   o  *False Negatives* - Because so many different heuristics are used
      to detect a captive portal, it's common for an OS or browser to
      think it's on an open network, when in fact there is a captive
      portal [4] in place.





Nottingham               Expires October 6, 2016                [Page 3]

Internet-Draft          CAPPORT Problem Statement             April 2016


   o  *Longevity* - Often, it's necessary to repeatedly log into a
      captive portal [5], thanks to timeout issues.  The effects of this
      range from annoyance to inability to complete tasks, depending on
      the timeout and the task at hand.

   o  *Interoperability Issues* - Captive portals often depend on
      specific operating system and browser capabilities and behaviours.
      Client systems that do not share those quirks often have
      difficulty connecting to captive portals.

   o  *Confusion* - Because captive portals are effectively a man-in-
      the-middle attack, they can confuse users as well as user agents
      (e.g., caches).  For example, when the portal's TLS certificate
      doesn't match that of the requested site, or the captive portal's
      /favicon.ico gets used as that of the originally requested site.

   o  *DNS*/*DNSSEC* - When portals respond with forged DNS answers,
      they confuse DNS resolvers and interoperate poorly with host-
      validating DNSSEC resolvers and applications.

   o  *TLS* - Portals that attempt to intercept TLS sessions (HTTPS,
      IMAPS, or other) can cause certificate error messages on clients,
      encouraging bad practice to click through such errors.

   o  *Unexpected Configuration* - Some captive portals do not work with
      clients using unexpected configurations, for example clients using
      static IP, custom DNS servers, or HTTP proxies.

   o  *Stealing Access* - because captive portals often associate a user
      with a MAC address, it is possible for an attacker to impersonate
      an authenticated client (e.g., one that has paid for Internet
      access).  Note that this is specific to open Wifi, and can be
      prevented by using a secure wireless medium.  However,
      configuration of secure wireless is often deemed to be too complex
      for captive networks.

   o  *Non-Browser Clients* - It is becoming more common for Internet
      devices without the ability to run a browser to be used, thanks to
      the "Internet of Things."  These devices cannot easily use most
      networks that interpose a captive portal.

   o  *Connectivity Interruption* - For a device with multiple network
      interfaces (e.g., cellular and WiFi), connecting to a network can
      require dropping access to alternative network interfaces.  If
      such a device connects to a network with a captive portal, it can
      lose network connectivity until the captive portal requirements
      are satisfied.




Nottingham               Expires October 6, 2016                [Page 4]

Internet-Draft          CAPPORT Problem Statement             April 2016


4.  Issues Caused by Captive Portal Detection

   Many operating systems attempt to detect when they are on a captive
   network.  Detection aims to minimize the negative effects caused by
   interposition of captive portals, but can cause different issues,
   including:

   o  *False Positives* - Some networks don't use a Web browser
      interface to log in; e.g., they require a VPN to access the
      network [6], so captive portal detection relying on HTTP is
      counterproductive.

   o  *Non-Internet Networks* - Some applications [7] and/or networks
      don't assume Internet access, but captive portal detection often
      conflates "network access" with "Internet access".

   o  *Sandboxing* - When a captive portal is detected, some operating
      systems access the captive portal in a highly sandboxed captive
      portal browser.  This might have reduced capabilities, such as
      limited access to browser APIs.  In addition, this environment is
      separate from a user's normal browsing environment and therefore
      does not include state.  While sandboxing seems a good idea to
      protect user data (particularly on Open WiFi), it is implemented
      differently on various platforms and often causes a (severely)
      broken user experience on the captive portal (even when the
      operator is protecting user data end-to-end with HTTPS).  To offer
      a consistent and rich experience on the captive portal, some
      operators actively try to defeat operating system captive portal
      detection.

4.1.  Issues Caused by Defeating Captive Portal Detection

   Many captive portal devices provide optional mechanisms that aim to
   defeat captive portal detection.

   Such defeat mechanisms aim to avoid the problems caused by captive
   portal detection (see Section 4), with the consequence that they also
   cause the same problems that detection was intended to avoid (see
   Section 3).

5.  Security Considerations

   TBD








Nottingham               Expires October 6, 2016                [Page 5]

Internet-Draft          CAPPORT Problem Statement             April 2016


6.  References

6.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
              RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC6108]  Chung, C., Kasyanov, A., Livingood, J., Mody, N., and B.
              Van Lieu, "Comcast's Web Notification System Design", RFC
              6108, DOI 10.17487/RFC6108, February 2011,
              <http://www.rfc-editor.org/info/rfc6108>.

6.2.  URIs

   [1] https://discussions.apple.com/thread/6251349

   [2] https://community.aerohive.com/aerohive/topics/
       ios_7_captive_portal_issues

   [3] http://stackoverflow.com/questions/14606131/using-captive-
       network-assistant-on-macosx-to-connect-to-vpn

   [4] http://forum.piratebox.cc/read.php?9,8879

   [5] https://github.com/httpwg/wiki/wiki/Captive-Portals

Appendix A.  Acknowledgements

   This draft was seeded from the HTTP Working Group Wiki Page on
   Captive Portals [8]; thanks to all who contributed there.

   Thanks to Martin Thomson, Yaron Sheffer, David Bird and Jason
   Livingood for their suggestions.

Author's Address

   Mark Nottingham

   Email: mnot@mnot.net
   URI:   https://www.mnot.net/









Nottingham               Expires October 6, 2016                [Page 6]
