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

[Warren Kumari <[e-mail]>]

On Tue, Jun 9, 2020 at 8:46 PM Benjamin Kaduk via Datatracker
<[e-mail]> wrote:
>
> 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.

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.

>
>
> ----------------------------------------------------------------------
> 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.

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.

>
>    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?

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

>
>    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]

DONE. Thank you. As above.

>
> 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.

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

>
>    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"?

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?

>
>    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.

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

>
>    "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?

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

>
>    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.)

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

>
>    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.

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

>
> Section 2.1
>
>    o  Len: The length (one octet), in octets of the URI.
>
> nit: comma after "in octets" as well as before.

DONE. Thank you.

>
> 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]
>

DONE. Thank you. 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".
>

DONE. Thank you.

>    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?

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

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

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

>
> 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?

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.


>
> 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?

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

>
>    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?

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."

>
>    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.)
>

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

>    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.

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."

>
> 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.

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