[Captive-portals] Benjamin Kaduk's Discuss on draft-ietf-capport-rfc7710bis-07: (with DISCUSS and COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-capport-rfc7710bis-07: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-capport-rfc7710bis/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

There seems to be an internal inconsistency about whether, when the API
URL is available in a given network via multiple mechanisms, the URLs
provided by the different mechanisms must be "identical" (Section 3) or
merely "equivalent" (Section 2).  I think we need to be consistent in
the requirement, as it is possible for URLs to be equivalent but not
identical just by virtue of mundane encoding tricks, even without
getting to the question of semantic equivalence of pointed-to resources.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

There is perhaps something to be said about how us moving from DHCP code
point 160 to 114 is in effect making a mockery of the registration
policy of IETF Review, when it is in practice First Come First Served as
the squatter wins.  I think we should consider making a stronger
statement about squatting being bad (though if I understand correctly
for this case, the registration policy in this range has changed since
the creation of the registry, so maybe there are extenuating
circumstances).  [N.B. that this is the COMMENT section, not the DISCUSS section.]

I also think we should be more explicit about the potential gap in the
chain of custody for getting the user to the captive portal server to
fulfil the Captive Portal Conditions.  In order for the user to trust
that they're in the right place (even as they may be, e.g., entering
payment information), they rely on the network to only provide
legitimate versions of the signals defined in this document, blocking
sppofed ones.  At present, this seems to involve a component of "blind
faith", and though we do discuss the technical capabilities of the
attacker we don't go into how this affects the "trust chain" from
initial network attachment.  (More discussion in the section-by-section
comments.)

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.

side note: I don't remember seeing "customer" used in the architecture or API
document.

   This document describes a DHCPv4 and DHCPv6 option and a Router
   Advertisement (RA) option to inform clients that they are behind some
   sort of captive-portal enforcement device, and that they will need to
   authenticate to get Internet access.  It is not a full solution to

In the terminology of the architecture doc, the client will "satisfy the
Captive Portal Conditions" (as opposed to "authenticate").  Is there a
reason to use divergent terminology?

   hosts to interact with such portals.  While this document defines how
   the network operator may convey the captive portal API endpoint to
   hosts, the specific methods of authenticating to, and interacting
   with the captive portal are out of scope of this document.

["authenticating" again]

Section 2

   information faster and more reliably.  Note that, for the foreseeable
   future, captive portals will still need to implement interception
   techniques to serve legacy clients, and clients will need to perform
   probing to detect captive portals.

side note: I'd consider reiterating the "faster and more reliably" here
to incentivize adoption of the new mechanisms even though the legacy
ones are still needed.

   to reduce the chance of operational problems.  The maximum length of
   the URI that can be carried in IPv4 DHCP is 255 bytes, so URIs longer
   than 255 bytes should not be provisioned via IPv6 DHCP nor IPv6 RA
   options.

I'm not sure whether this text is conveying the intended meaning -- the
current version sounds like it's saying that because IPv4 DHCP is
limited, we need an entirely new mechanism to convey longer URIs,
leaving the reader to guess that this is out of some desire to keep the
existing mechanisms at feature parity.  Is the intent more along the
lines of "URIs longer than 255 bytes should not be used at all, so that
it's easier to present a consistent view across the three different
provisioning mechanisms defined in this document"?

   In all variants of this option, the URI MUST be that of the captive
   portal API endpoint, conforming to the recommendations for such URIs
   [draft-ietf-capport-api].

I'm sympathetic to the intdir reviewer's comments about the
"recommendations" from draft-ietf-capport-api not being laid out
particularly clearly.

   "user-portal-url" API key.  When performing such content negotiation
   ([RFC7231] Section 3.4), implementors of captive portals need to keep
   in mind that such responses might be cached, and therefore SHOULD
   include an appropriate Vary header field ([RFC7231] Section 7.1.4) or
   mark them explicitly uncacheable (for example, using Cache-Control:
   no-store [RFC7234] Section 5.2.2.3).

The API doc says "'private' or a more restrictive value"; do we want to
be diverging from that recommendation?

   The URI SHOULD NOT contain an IP address literal.  Exceptions to this
   might include networks with only one operational IP address family
   where DNS is either not available or not fully functional until the
   captive portal has been satisfied.

If we don't heed the SHOULD then we end up trying to speak TLS with only
an IP address for the server identifier, so we want an iPAddress
certificate, which adds complications of its own.  (Perhaps most of the
discussion of these complications should be in the API document, and
I'm pretty amenable to arguments that they are out of scope for
*extended* discussion here.  I'd still like to see a brief mention that
this scenario has some complications.)

   Networks with no captive portals MAY explicitly indicate this
   condition by using this option with the IANA-assigned URI for this
   purpose.  Clients observing the URI value
   "urn:ietf:params:capport:unrestricted" MAY forego time-consuming
   forms of captive portal detection.

It's not entirely clear that the BCP 14 "MAY" is adding much here.

Section 2.1

   o  Len: The length (one octet), in octets of the URI.

nit: comma after "in octets" as well as before.

Section 2.2

   The maximum length of the URI that can be carried in IPv4 DHCP is 255
   bytes, so URIs longer than 255 bytes should not be provisioned via
   IPv6 DHCP options.

[similar comment as above]

Section 2.3

   URI  The URI for the captive portal API endpoint to which the user
      should connect.  This MUST be padded with NULL (0x00) to make the

nit: in the context of (ASCII) characters, the octet with all bits zero
is usually written a "NUL", not "NULL".

   Note that the URI parameter is not guaranteed to be null terminated.

(ditto)

   The maximum length of the URI that can be carried in IPv4 DHCP is 255
   bytes, so URIs longer than 255 bytes should not be provisioned via
   IPv6 RA options.

[similar comment as above]

Section 4

Shouldn't we also request the reference be updated for the DHCPv6 option
code and RA option type?

Section 4.1

(I assume the question of "capport:unrestricted" vs.
"capport-unrestricted" was discussed already and don't wish to rehash it
again.)

Section 4.2

If this document is just de-registering the former capport use of code
160, what process is going to mark it as used for the polycom thing?

Section 5

RFC 7227 (BCP 187) "strongly advises" authors of documents defining new
DHCP options to define validation measures for recipients of such
options.  I don't see any such validation measures specified in this
document; why is it okay to diverge from the BCP recommendation?

   By removing or reducing the need for captive portals to perform MITM
   hijacking, this mechanism improves security by making the portal and
   its actions visible, rather than hidden, and reduces the likelihood
   that users will disable useful security safeguards like DNSSEC
   validation, VPNs, etc.  In addition, because the system knows that it

Perhaps we should say why the users would be disabling those mechanisms
in the absence of this mechanism?

   credentials, etc.  By handing out a URI which is protected with TLS,
   the captive portal operator can attempt to reassure the user that the
   captive portal is not malicious.

It's not entirely clear how successful such attempts will be, though, as
the trustworthiness of the captive-portal provisioning signal depends on
the network operator implementing (e.g.) RA-guard and DHCP sheild to
prevent the client from receiving signals not authorized by the network
operator, and the client does not in general know whether or not that is
the case.  (While we do talk about those mechanisms in the following
paragraph, we don't really talk about how the user can('t) know for sure
that those mechanisms are in place.)

   However, as the operating systems and application that make use of
   this information know that they are connecting to a captive-portal
   device (as opposed to intercepted connections) they can render the

I think we want to clarify in the parenthetical that for the case of
intercepted connections the OS/application may not know that they are
connecting to a captive-portal or hostile device.

Appendix B

   2.  Clarify that the option URI SHOULD be that of the captive portal
       API endpoint.

I couldn't find where this is done -- I just see descriptive text that
the URI is the URI of the API endpoint.