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

[Eliot Lear <lear@xxxxxxxxx>]

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
ietf@xxxxxxxx mailing lists by 2015-09-17. Exceptionally, comments may be
sent to iesg@xxxxxxxx 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.

Attachment: signature.asc
Description: OpenPGP digital signature