Subject: Re: Last Call: <draft-wkumari-dhc-capport-16.txt> (Captive-Portal Identification in DHCP / RA) to Proposed Standard

From: Eliot Lear <[email-masked]>
Date: Thu, 3 Sep 2015 08:05:18 +0200

Hi,

I think this is a fine draft.

I have two comments relating to security considerations:

  * The author correctly identifies a threat of someone attempting to
    force an interaction with a portal when one is potentially not
    needed.  Has the author considered use of a simple "liveness" test
    to determine whether communication with the portal is really
    required?  That is, if you can already get to all things Internet,
    why bother contacting the portal at all?  Furthermore, if the URI in
    the DHCP response were required to use the HTTPS scheme, that would
    require that an attacker have a valid TLS certificate, which would
    at least leave a trail if there were a problem.  Was this
    possibility discussed?

  * While the proposed RA and DHCP options don't make matters worse in
    this regard, it wouldn't kill anyone if advice was given to portal
    people that stated that they should allow communications for
    necessary CRLs to be retrieved.  This will reduce the need for any
    special handling on the part of a myriad of clients.

Regards,

Eliot

On 9/3/15 12:55 AM, The IESG wrote:
> The IESG has received a request from an individual submitter to consider
> the following document:
> - 'Captive-Portal Identification in DHCP / RA'
>   <draft-wkumari-dhc-capport-16.txt> as Proposed Standard
>
> While the original last call went out correctly with a  a 4 week peroid due 
> to the standards action required for DHCP registration the last call
> erroneously stated that the status for which the draft was aiming was 
> informational. The intended status is proposed standard. This additional
> last call intended to clarify that point runs for two weeks completing 
> 9/17.
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2015-09-17. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>
>    In many environments offering short-term or temporary Internet access
>    (such as coffee shops), it is common to start new connections in a
>    captive portal mode.  This highly restricts what the customer can do
>    until the customer has authenticated.
>
>    This document describes a DHCP option (and a RA extension) to inform
>    clients that they are behind some sort of captive portal device, and
>    that they will need to authenticate to get Internet Access.  It is
>    not a full solution to address all of the issues that clients may
>    have with captive portals; it is designed to be used in larger
>    solutions.  The method of authenticating to, and interacting with the
>    captive portal is out of scope of this document.
>
>    [ Ed note (remove): This document is being developed in github:
>    https://github.com/wkumari/draft-wkumari-dhc-capport . ]
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-wkumari-dhc-capport/
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-wkumari-dhc-capport/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
>