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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Tue, 09 Jun 2020 17:46:01 -0700

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.

---

From: Warren Kumari <[email-masked]>
Date: Tue, 23 Jun 2020 19:25:24 -0400

> https://datatracker.ietf.org/doc/draft-ietf-capport-rfc7710bis/

Thank you - we have addressed this in the most recent commit by using
"identical" and adding some words.
Please confirm that these meet with your approval.

DONE.
Thank you - we have gone with "user" (to address others comments) - I
was picturing someone (a customer) buying coffee, and so that is where
this usage originally came from.

> reason to use divergent terminology?

DONE. Thank you -- using "satisfy the Captive Portal conditions"

>    with the captive portal are out of scope of this document.

DONE. Thank you. As above.

> to incentivize adoption of the new mechanisms even though the legacy

Thank you -- we were not able to parse this suggestion - unless you
were suggesting that the second sentence say that legacy clients don't
benefit from this?
Please provide text :-P

> provisioning mechanisms defined in this document"?

DONE. Thank you.
We changed this to: "As the maximum length
   of the URI that can be carried in IPv4 DHCP is 255 bytes, URIs longer
   than this SHOULD NOT be provisioned by any of the IPv6 options
   described in this document.  In IPv6-only environments this
   restriction can be relaxed."

Does that address your concern?

> "recommendations" from draft-ietf-capport-api not being laid out

Ah, good point - we took the Intdir reviewers suggestion and dropped
the subclause.

> be diverging from that recommendation?

DONE. Thank you, good catch. We plagiarized from the API document :-)

> this scenario has some complications.)

DONE. Thank you. We largely stole your above text, and added a
reference to 3779.

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

DONE. Thank you - it was fairly clear that it doesn't add much, and so
we made them "may".

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

DONE. Thank you.

> [similar comment as above]

DONE. Thank you. As above.

> is usually written a "NUL", not "NULL".

DONE. Thank you.

> Shouldn't we also request the reference be updated for the DHCPv6 option

DONE. Thank you (Magnus had a discuss on this)

> "capport-unrestricted" was discussed already and don't wish to rehash it

Thank you, yes, we had a discussion with Barry and Martin on this.

> 160, what process is going to mark it as used for the polycom thing?

We have updated the IANA considerations section to say:

   Tag: 160
   Name: Unassigned
   Data Length:
   Meaning: Previously assigned by RFC7710; known to also be used by Polycom.
   Reference: [THIS-RFC][RFC7710]

This seems to be the right way to refer to is, but, as always, we will
discuss with IANA.

> document; why is it okay to diverge from the BCP recommendation?

DONE. Thank you.
Added:
Clients processing these options SHOULD validate that the option's
contents conform to the validation requirements for URIs, including
RFC3986.

> in the absence of this mechanism?

DONE. Thank you. - "... reduces the likelihood that users will disable
useful security safeguards like DNSSEC validation and VPNs, in order
to interact with the captive portal."

> that those mechanisms are in place.)

Agreed, but this is better than the current situation....

> connecting to a captive-portal or hostile device.

DONE. Thank you. Added your text into the parenthetical, it now says:
" however, as the operating systems and application(s) that make use
of this information know that they are connecting to a captive-portal
device (as opposed to intercepted connections where the OS/application
may not know that they are connecting to a captive portal or hostile
device) they can render the page in a sandboxed environment and take
other precautions, such as clearly labeling the page as untrusted."

> the URI is the URI of the API endpoint.

This is in Section 2, paragraph 4:
"In all variants of this option, the URI MUST be that of the captive
portal API endpoint [draft-ietf-capport-api]." - we had the discussion
on this in the WG, and so we are updating Appendix B to say MUST.
Great catch!

Thank you for all of your comments, I think that we have addressed them now.

Thanks you,
  Warren and Erik

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 30 Jun 2020 13:50:11 -0700

Hi Warren and Erik,

> Please confirm that these meet with your approval.

Yes, this looks good, and I've cleared my Discuss in the datatracker (but
had it not send mail, since I'm sending this one).

> were suggesting that the second sentence say that legacy clients don't

I was just thinking that if we have a whole sentence about how "you're
going to have to do the old thing anyway, though", someone might read that
and say "well, if I have to keep doing the old thing, why should I bother
with this new thing".  So, appending a "; nonetheless, the mechanism
provided by this document provides a more reliable and performant way to do
so, and is therefore the preferred mechanism for captive-portal detection"
or similar is what I had in mind.

> Does that address your concern?

That text looks good, thanks.  Whether or not it matches up with my
previous understanding of the intent is not super-relevant :)

> This seems to be the right way to refer to is, but, as always, we will

Sounds good, thanks.

> on this in the WG, and so we are updating Appendix B to say MUST.

Ah, got it.

Thanks for the updates!

-Ben