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(_at_)ietf(_dot_)org mailing lists by 2015-09-17. Exceptionally, comments
may be
sent to iesg(_at_)ietf(_dot_)org 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.
signature.asc
Description: OpenPGP digital signature