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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Mon, 08 Jun 2020 22:30:36 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-capport-architecture-08: 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-architecture/

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

(1) and (2) should be easy to fix; (3) may well be "fixed" by telling me
I'm too naive :)

(1) Given that section 1 describes other options, the abstract should not
limit to just DHCP and RA as options for provisioning the API URL.

(2) Section 4.1 says that:

   5.  The Captive Portal API server indicates to the Enforcement Device
       that the User Equipment is allowed to access the external
       network.

but I believe this should be the "Captive Portal Server" (or, as the
previous point has it, the "web portal").

(3) Probably a "discuss discuss", but ... in Section 1 we have:

   *  Solutions SHOULD NOT require the forging of responses from DNS or
      HTTP servers, or any other protocol.  In particular, solutions
      SHOULD NOT require man-in-the-middle proxy of TLS traffic.

I'd like to understand the motivation for this one a little better.
Naively, it seems like we could get away with "MUST NOT require" while
still allowing it to be done.  Am I missing something obvious?

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

I'd like to see some more discussion of which signals are authenticated
and how, and what kind of authorization checks are possible.  In
well-run networks DHCP and RA signals should be relatively trustworthy,
but clients don't always have a good indicator for whether a given
network falls into that category.  Are there (other) mechanisms that can
be used to give trust in the authenticity of a given Captive Portal API
URI and that that API is authorthorized to provide unconstrained access
for the network in question?  We require TLS for accessing the API
server, but (as I note inline) there are more details that can be given
about this TLS usage.  What can be done to authenticate and authorize
the Captive Portal Server?  Most importantly (and most appropriately for
an architecture document), which of these properties are strictly
required vs. merely optional?  These are not Discuss-level points
because an architecture does not strictly-speaking need to specify all
of them, but having some indication of how we plan to achieve them would
give greater confidence that this architecture will be a useful one.

I'm happy to see the response to the genart reviewer's comment regarding
"a" vs. "the" capport architecture; thanks!

Abstract

   This document describes a CAPPORT architecture.  DHCP or Router
   Advertisements, an optional signaling protocol, and an HTTP API are
   used to provide the solution.  The role of Provisioning Domains

nit: there's perhaps a bit of a lack of parallelism in the list
structure, where we talk about specific mechanisms for provisioning
without describing the more abstract concept of provisioning, and list
that alongside an abstract mention of "a signaling protocol" and the
both-abstract-and-concrete "HTTP API".

Section 1

   Implementations generally require a web server, some method to allow/
   block traffic, and some method to alert the user.  Common methods of

nit: I'd suggest clarifying that this is "implementations of captive
portals" (or is it "captive networks"?).

   alerting the user involve modifying HTTP or DNS traffic.

nit: perhaps "at present" or "prior to this work"?  If I understand
correctly one of the goals of this work is to shift the balance of
captive portals away from these practices (while acknowledging that
fully eliminating them is not feasible in the near future).

   *  Solutions MAY allow a device to be alerted that it is in a captive
      network when attempting to use any application on the network.

I'm also not sure I understand this one, especially in light of the
following (paraphrased) "SHOULD allow learning of captivity before
application attempts to use the network".  What's the alternative to
"MAY allow", not-allowing such detection at all?

   *  The architecture MUST provide a path of incremental migration,
      acknowledging a huge variety of portals and end-user device
      implementations and software versions.

nit: "preexisting" or similar would go a long way here.

   *  Network provisioning protocols provide end-user devices with a

side note: using the word "provisioning" to describe things like DHCP
and RA feels odd to me, presumably due to my background and what I
expect provisioning to be.  I can see why it makes sense to use the term
for this purpose, though.  Perhaps an additional adjective could help
clarify what is meant, though I don't have a suggestion at hand.

      for this purpose are available in [RFC7710bis].  Other protocols
      (such as RADIUS), Provisioning Domains [I-D.pfister-capport-pvd],
      or static configuration may also be used.  A device MAY query this

side note: personally, I'd expand to "may also be used to convey this
API URI", though it's probably not required for clarity.

      The device MAY take immediate action to satisfy the portal
      (according to its configuration/policy).

side note: it's not entirely clear to me that we need a normative MAY
for this.

Section 2.1

   have Internet access).  The User Equipment communication is typically
   restricted by the Enforcement Device, described in Section 2.4, until
   site-specific requirements have been met.

It seems like these "site-specific requirements" must be the "Captive
Portal Conditions" that we just defined.

   *  SHOULD have a mechanism for notifying the user of the Captive
      Portal

It is pretty important that this mechanism be non-spoofable by, e.g.,
untrusted websites.  I think we should mention something about
"non-spoofable" here.

   *  MAY prevent applications from using networks that do not grant
      full network access.  E.g., a device connected to a mobile network
      may be connecting to a captive WiFi network; the operating system
      MAY avoid updating the default route until network access
      restrictions have been lifted (excepting access to the Captive

nit: maybe say in which direction the update would go and/or something
about why the move to wifi is desirable?

   None of the above requirements are mandatory because (a) we do not
   wish to say users or devices must seek full access to the captive
   network, (b) the requirements may be fulfilled by manually visiting
   the captive portal web application, and (c) legacy devices must
   continue to be supported.

side note: in my opinion, it's possible to support legacy devices in
practice without baking their limitations into the spec.

   If User Equipment supports the Captive Portal API, it MUST validate
   the API server's TLS certificate (see [RFC2818]).  An Enforcement

We should probably cite RFC 6125 here and say something about how the UE
gets a name to validate the server's certificate against (and what name
type to use).

   [I-D.ietf-capport-api] for more information.  If certificate
   validation fails, User Equipment MUST NOT proceed with any of the
   behavior described above.

I'm not sure which behavior the "behavior described above" is.
"[accessing...] OCSP responders, CRLs, and NTP servers" doesn't seem
quite right since that's *how* you determine that certificate validation
fails, but the bits further up about "navigate [to] the Captive Portal
user interface" do not seem to clearly call out a single behavior or set
of behaviors by the UE.

Section 2.2.2

   Although still a work in progress, [I-D.pfister-capport-pvd] proposes
   a mechanism for User Equipment to be provided with PvD Bootstrap
   Information containing the URI for the JSON-based API described in
   Section 2.3.

I don't think "JSON-based" is supported by the text of § 2.3 (and isn't
really appropriate for an architecture doc in most cases, anyway).

Section 2.3

   The purpose of a Captive Portal API is to permit a query of Captive
   Portal state without interrupting the user.  This API thereby removes
   the need for User Equipment to perform clear-text "canary" HTTP
   queries to check for response tampering.

nit: probably don't need to be specific about HTTP, here.

   At minimum, the API MUST provide: (1) the state of captivity and (2)
   a URI for the Captive Portal Server.

Is there anything useful to say about the URI scheme for the captive
portal server URI?  I guess I could probably (grudgingly) come up with a
case where http-not-s would be tolerable, but given that we admit the
possibility of "payment" as a captive portal condition, I don't want us
to encourage sending payment or other sensitive information over schemes
inappropriate for such information.

   A caller to the API needs to be presented with evidence that the
   content it is receiving is for a version of the API that it supports.

What about evidence that the content it is receiving is intended to be
used with, and authorized to speak for, the network it is joining?

   When User Equipment receives Captive Portal Signals, the User
   Equipment MAY query the API to check the state.  The User Equipment

nit: we seem to use "the state of its captivity" most places.

   The API MUST use TLS to ensure server authentication.  The
   implementation of the API MUST ensure both confidentiality and
   integrity of any information provided by or required by it.

It's a little weird to split the TLS requirements between here and
Section 2.1, though I guess if we're splitting things by role it's
probably unavoidable.  (I made my RFC 6125 comment in Section 2.1 and it
probably doesn't need to appear in both places.)

Section 2.4

   *  May signal User Equipment using the Captive Portal Signaling
      protocol if certain traffic is blocked.

nit: I think that "optionally signals" might be a better fit for the
list structure as used in the other bullet points.

Section 2.5

   When User Equipment first connects to a network, or when there are
   changes in status, the Enforcement Device could generate a signal
   toward the User Equipment.  This signal indicates that the User
   Equipment might need to contact the API Server to receive updated
   information.  For instance, this signal might be generated when the
   end of a session is imminent, or when network access was denied.

Would this signal also be used when the UE has successfully met the
Captive Portal Conditions?

Section 2.6

   *  The User Equipment queries the API to learn of its state of
      captivity.  If captive, the User Equipment presents the portal
      user interface from the Web Portal Server to the user.

[we previously discussed this UE behavior as optional.  I don't mind
having the text be descriptive like this, since it's describing the
diagram, and the diagram is not binding on all UEs, but it seemed worth
noting just in case.]

Section 3.1

   An Identifier is a characteristic of the User Equipment used by the
   components of a Captive Portal to uniquely determine which specific
   User Equipment is interacting with them.  An Identifier MAY be a

Do we want to say anything about what scope within which the uniqueness
must hold?  ("No" is probably fine.)

Section 3.2.1

   Each instance of User Equipment interacting with the Captive Network
   MUST be given an identifier that is unique among User Equipment
   interacting at that time.

side note: "MUST be given" gets a knee-jerk "by whom?" response from me.
It's probably okay for this document to not specify, though, as it may
depend on the nature of the Captive Network.

   Over time, the User Equipment assigned to an identifier value MAY
   change.  Allowing the identified device to change over time ensures
   that the space of possible identifying values need not be overly
   large.

Is the identifier assigned to a given UE on the same network expected to
be able to change as well?  This may have some privacy considerations...

Section 3.2.2

   are active at the same time.  This property is particularly important
   when the User Equipment is extended externally to devices such as
   billing systems, or where the identity of the User Equipment could
   imply liability.

nit(?): is it the UE that is extended externally or the identifier
thereof?

Section 3.2.4

   In some situations, the User Equipment may have multiple IP
   addresses, while still satisfying all of the recommended properties.

nit: as written, "while still satisfying all of the recommended
properties" is describing the UE, but the context of Section 3.4
suggests that we want to be talking about the recommended properties for
identifiers.

Section 3.5

   Accessing the API MAY depend on contextual information.  However, the
   URIs provided in the API SHOULD be unique to the UE and not dependent
   on contextual information to function correctly.

Should the per-UE APIs and/or the mapping between UE and per-UE API be
unguessable?  (Do we want to reference Capability URLs
[https://www.w3.org/TR/capability-urls/]?)

Section 4

I might consider explicitly saying "non-normative" somewhere in here.

Section 4.1

   4.  If necessary, the User navigates the web portal to gain access to
       the external network.

nit: "navigates to"

Section 4.2

   3.  The User Equipment's UI indicates that the length of time left
       for its access has fallen below a threshold

   4.  The User Equipment visits the API again to validate the expiry
       time

side note: I feel like there's implicitly some User action in here,
though I don't know that we need to actually say anything about it.
(Otherwise we wouldn't have the UI indicating things.)

Section 4.3

   Whenever a new Portal URI is received by end User Equipment, it
   SHOULD discard the old URI and use the new one for future requests to
   the API.

What kind of validation/authorization checks need to be applied to the
new Portal URI?

(nit: we probably should check the terminology in this section; the
Section 1.2 lexicon would call this information the "Captive Portal API
Server URI" and not a "Portal URI".)

Section 7

This mechanism rather inherently requires having multiple entities track
the UE's identity (and, thus, likely be tracking a proxy for the user's
identity).  It seems appropriate to include some discussion of the
privacy considerations of this tracking, and whether/what kind of
anonymity support is appropriate!

Section 7.1

   Given that a user chooses to visit a Captive Portal URI, the URI
   location SHOULD be securely provided to the user's device.  E.g., the
   DHCPv6 AUTH option can sign this information.

I'm not sure that I understand the intent behind the "Given that"
construction here.  Is it trying to emphasize user choice, and thus the
need for informed choice?

Section 7.2

[In the vein of my previous remarks, there are many ways to use TLS, and
usually we provide more details on how we expect TLS to be used.]

Section 7.3

   The API MUST ensure the integrity of this information, as well as its
   confidentiality.

Who/what is the attacker(s) that we need to preserve confidentiality from?

Section 7.4

   *  Accesses to the API Server are rate limited, limiting the impact
      of a repeated attack.

One might consider a flooding attack that tries to get the UE to use all
its (rate-limited) connections to get some information that is not the
information that it's most important for the UE to have.  If there's
only a single operation that can be performed at the API Server (which I
believe is the intent?) there is no such attack, but it may be worth
mentioning that there is no such attack.

Section 8.1

Interestingly, none of the places where we reference 7710bis have
surrounding text that clearly incur a normative dependency.

Appendix A

We explain the use of the "canary" term here, but have already used it
twice (with no forward-reference) in the body of the document.

   Another test that can be performed is a DNS lookup to a known address
   with an expected answer.  If the answer differs from the expected
   answer, the equipment detects that a captive portal is present.  DNS
   queries over TCP or HTTPS are less likely to be modified than DNS
   queries over UDP due to the complexity of implementation.

Is the reader supposed to draw the conclusion that DoTCP/DoH provide
less-reliable captive-portal detection than Do53?  (I assume "TCP" is
not a typo for "TLS", here, though am unsure enough to want to check.)

   Malicious or misconfigured networks with a captive portal present may
   not intercept these requests and choose to pass them through or
   decide to impersonate, leading to the device having a false negative.

nit: I suggest "these 'canary' requests" to clarify which requests we're
talking about.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 09 Jun 2020 12:26:57 -0400

> HTTP servers, or any other protocol.  In particular, solutions SHOULD
    > NOT require man-in-the-middle proxy of TLS traffic.

    > still allowing it to be done.  Am I missing something obvious?

Speaking as a contributor,
a) I hate "SHOULD NOT", and "MUST NOT", because I find it confusing
   to non-native english speakers, and so I'd rather write in the form
   of positive statements.
      Solutions MUST permit clients to perform DNSSEC validation,
      which rules out solutions that forge DNS responses.

      Solutions SHOULD permit clients to detect and avoid TLS
      man-in-the-middle attacks without requiring a human to
      perform any kind of "exception" processing.

b) I think that we have "SHOULD NOT" for TLS, because there are many
   Windows-Group-Policy situations which have been deployed where the
   MITM is official and is authenticated, but this fails for BYOD.
   While most of the captive portals we are aware of are at airports, etc.
   they are also used for corporate guest networks, and when writing
   an RFP for such a thing, we need this document to describe something
   sensible.

    > network falls into that category.  Are there (other) mechanisms that
    > can be used to give trust in the authenticity of a given Captive Portal
    > API URI and that that API is authorthorized to provide unconstrained
    > access for the network in question?

Yes, there are mechanisms, but they are very specific to the client operating
systems involved, and they are not standardized.  Most index upon the ESSID
identity to catagorize the network into "Home" / "Work" / "Public", to use
the Windows terminology.
I think that the WG decided that this was a rathole we did not need to go
into, particularly for a PS.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Kyle Larose <[email-masked]>
Date: Thu, 11 Jun 2020 09:12:34 -0400

Hi Benjamin,

Thanks for the thorough review!

Responses inline

> draft-ietf-capport-architecture-08: Discuss

Should be simple enough to open up the wording. E.g.

"Network provisioning protocols such as DHCP or Router Advertisements,
an optional signaling protocol..."

> previous point has it, the "web portal").

You're right. We'll change it up.

> still allowing it to be done.  Am I missing something obvious?

I'll continue the discussion here by replying to Michael's reply.

I  think my proposal in response to your Discuss for this section
addresses this. Does it?

> portals" (or is it "captive networks"?).

Will do

> fully eliminating them is not feasible in the near future).

Fair point. I'd hope that readers of this statement 10 years from now would
be confused unless we change it!

> "MAY allow", not-allowing such detection at all?

In short, the SHOULD case is covered by using network provisioning/the
API to discover
whether you're captive, and the MAY case is covered by using the
Captive Portal Signal.

Perhaps rephrasing "MAY allow" to "MAY implement a signal to alert a
device that ..."
 would clarify the meaning of the requirement? Similarly, rephrase
"SHOULD allow" to
 "SHOULD implement a mechanism whereby a device can learn ..."

> nit: "preexisting" or similar would go a long way here.

Will change. e.g. "...a huge variety of preexisting portals..."

> clarify what is meant, though I don't have a suggestion at hand.

I'm not really an expert in this area. Does anyone have any alternatives, or
reasons why we should stick with "network provisioning"?

> API URI", though it's probably not required for clarity.

Your suggestion reads better. We'll make the change.

> side note: it's not entirely clear to me that we need a normative MAY

I think you're right. Anyone else have an opinion on this?

> untrusted websites.  I think we should mention something about

To clarify, an example spoofed notification would be a browser notification
sent from one of these untrusted sites? Seems reasonable. How much detail
do you think we need to get into about what it means to be non-spoofable?
Is it sufficient to just say "SHOULD have a non-spoofable mechanism..."?

> about why the move to wifi is desirable?

How about "... the operating system MAY avoid updating the default route
to a device on the captive WiFi network until ..."

> gets a name to validate the server's certificate against (and what name

We can do this.

> user interface" do not seem to clearly call out a single behavior or set

Yeah, this is a bit ambiguous. It's meant to basically say: "Stop
interacting with the API". We can
probably rephrase to "If certificate validation fails, the User
Equipment MUST NOT make any calls to
the API Server".

> really appropriate for an architecture doc in most cases, anyway).

I agree. We'll drop "JSON-based".

> nit: probably don't need to be specific about HTTP, here.

I agree. Will remove HTTP.

> inappropriate for such information.\

I think that's reasonable. Does anyone have an objection to this? I
would at least
like to recommend that it's TLS, so it's considered.

> used with, and authorized to speak for, the network it is joining?

I'm not quite sure how we'd achieve this.  The only information the network
has given to the User Equipment is the URI for the Captive Portal API, which,
I think, it can assume covers those cases. This particular point was
simply intended
to ensure that the API had a method of ensuring compatibility.

> nit: we seem to use "the state of its captivity" most places.

Will update.

> list structure as used in the other bullet points.

Will change.

> Captive Portal Conditions?

The intention was for it to indicate when there are problems (similar
to say a destination
unreachable ICMP message). But, the language isn't precise about
that... I'm not sure that's a
problem. Does anyone else have some thoughts on this? Should we
clarify it either way (make
explicit that it's for any state transition to 'access denied'?)

> diagram, and the diagram is not binding on all UEs, but it seemed worth

We could probably preface this section with a comment indicating that
it's covering the case
where the API provides a web portal uri

> must hold?  ("No" is probably fine.)

I think we're probably fine here. Anyone else agree/disagree?

> depend on the nature of the Captive Network.

What if we say "by the Captive Network"? I think that makes it clear
that it's the responsibility of
the network, though that does perhaps complicate things if the system
chooses to use the MAC address, for example, which isn't "given" by
the network. In that case, the network would use the MAC that it has
inferred from its communication with the UE to construct the identity
that it then gives to the UE. I guess it makes sense when put that
way.

But, perhaps "given" is the wrong term here? Should we rephrase to
"The Captive Network MUST associate the User Equipment with an
identifier that is unique among User Equipment that is interacting at
that time?"

> be able to change as well?  This may have some privacy considerations...

I think so. E.g. if a DHCP lease expires, or the UE reattaches
multiple times. What are the
privacy considerations you're thinking of?

> nit(?): is it the UE that is extended externally or the identifier

The identifier. Will update.

> suggests that we want to be talking about the recommended properties for

Will rephrase.

> [https://www.w3.org/TR/capability-urls/]?)

That's not a bad idea. Does anyone else have an opinion on this? I'm currently
planning on taking the suggestion of mentioning that they should be
unguessable and
reference that document.

> I might consider explicitly saying "non-normative" somewhere in here.

Will do.

>    4.  If necessary, the User navigates the web portal to gain access to

Thanks. Will fix.

> (Otherwise we wouldn't have the UI indicating things.)

We may need to change this up a bit and then mention that the user
accepts the prompt. E.g.

   3.  The User Equipment's detects that the length of time left
       for its access has fallen below a threshold

   5.  If expiry is still imminent, the User Equipment prompts the user
       to access the web-portal URI again

   6. The user equipment accepts the prompt

   7.  The User extends their access through the web-portal via the UI

> What kind of validation/authorization checks need to be applied to the

This should be the same as the initial one we received when first
accessing the network
(e.g. via DHCP, RAs, etc). Perhaps we don't properly indicate
elsewhere that this should be supported. I thought we did, but I can't
find it...

I think we should add a point to Section 2.1 that the UE SHOULD
support updates to the captive portal URI from the network
provisioning service, and then mention here that that service is what
did it. The same trust as mentioned in section 7.1 still applies.

> Server URI" and not a "Portal URI".)

Will update
> anonymity support is appropriate!

That seems reasonable. I'll need to do some thinking on the text for
this, but a rough
first pass. I'm open to suggestions here, since I'm not a
security/privacy expert. I'll likely
get something wrong/miss something obvious.

Section 7.X  Privacy

  Section 3 describes a mechanism by which all components within the
Captive Network
  agree on a unique identifier for the User Equipment. This identifier
could be abused to
  track the user. Implementers and designers of Captive Networks
should take care to ensure
  that identifiers, if stored, are stored securely. Further,

> need for informed choice?

Yes. We should probably rephrase this

E.g.

"The user makes an informed choice in deciding to visit and trust the
Captive Portal URI. Since the network provides Captive Portal URI to
the user equipment, the
network SHOULD do so securely so that the user's trust in the network
can extend to their trust of the Captive Portal URI. E.g., the DHCPv6
AUTH option can sign this information."

> usually we provide more details on how we expect TLS to be used.]

We can expand on that here.

> Who/what is the attacker(s) that we need to preserve confidentiality from?

Without knowing the details of the particular solution, it's a bit
hard to say for sure, but roughly
I'd say it's someone who wants to interact with the API using the
identity of the user. E.g. if we're using an 'unguessable' URI, an
attacker snooping on the communication with the API could determine
the URI, and use it.

Does that sound reasonable?

> mentioning that there is no such attack.

In this case that's the intent (i.e. only visit to get whether we're
still captive). That's a good point, though: if we ever expand on
that, it could open the door to such an attack, so it's worth
mentioning why it's not a problem.

That said, I actually don't quite see how the uni-directional signal
could be used to get information back to the attacker. Could you maybe
describe that in a bit more detail?

> twice (with no forward-reference) in the body of the document.

Let's add a forward reference.

> not a typo for "TLS", here, though am unsure enough to want to check.)

Correct on both accounts. Do you think we should clarify the intent?

> nit: I suggest "these 'canary' requests" to clarify which requests we're

WIll change.

Thanks again!

Kyle

---

From: Kyle Larose <[email-masked]>
Date: Fri, 12 Jun 2020 08:19:50 -0400

Responses inline

>       perform any kind of "exception" processing.

I think I prefer turning this around like you've suggested. It
achieves the same goal,
but with, as you've said, less confusing language. We lose the
constraint on not
forging responses from other protocols, but I think that's covered by requiring
TLS for other interactions, and the next point about TLS MITM. Thanks for
the suggestion!

How do the other participants feel about this phrasing?

>    an RFP for such a thing, we need this document to describe something

Yes, this was the motivation.

> into, particularly for a PS.

Thanks,

Kyle

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 12 Jun 2020 17:50:41 -0700

Also inline.

> an optional signaling protocol..."

Indeed, that should work fine.

> I'll continue the discussion here by replying to Michael's reply.

Sounds good.  I expect we need to hear from more of the WG, but in
principle this seems like a reasonable approach.

> I  think my proposal in response to your Discuss for this section

I think so, thanks!

>  "SHOULD implement a mechanism whereby a device can learn ..."

Ah, I think I see now -- it's the *solution* (technology) that does the
allowing, not a given deployment.  The proposed rephrasings help make that
clear.

> Is it sufficient to just say "SHOULD have a non-spoofable mechanism..."?

A browser notification from an untrusted site, or even just javascript
content on such a site, yes.
I think it's probably sufficient to just say what you propose.  The next
step up would be something like "a non-spoofable mechanism that is
authenticated as originating from the UE and not an external party", but I
fear that would open up more questions than it answers.  (And we don't need
to go into an extended discussion of spoofing and trusted UI signals here!)

> to a device on the captive WiFi network until ..."

Works for me.

> > gets a name to validate the server's certificate against (and what name

Please feel free to reach out if you want advice on text to put here; it's
(unfortunately) a little prone to jargon.

> Equipment MUST NOT make any calls to

Okay.

> to ensure that the API had a method of ensuring compatibility.

Thanks for the clarification.  (I don't have a good answer for how to
achieve this offhand, either -- it seems to be one of the remaining gaps in
the system, per my comments on the API document.  But, the perfect need not
be the enemey of the good, so "document and move on" is reasonable.  And
this paragraph, at least, may not be the right place to document it anyway.

> where the API provides a web portal uri

Sure, that would work.

> identifier that is unique among User Equipment that is interacting at

That's a pretty good point; the association is more important than giving
or assignment.

> privacy considerations you're thinking of?

A device may seek to cause such an identity change simultaneously with
other privacy-promoting activities (like clearing cookies, changing MAC/IP
Address, etc.).  That's the main one that comes to mind, at least, though
privacy is a tricky area...

>    3.  The User Equipment's detects that the length of time left

(nit: s/'s//)

>    6. The user equipment accepts the prompt

(not sure if this is user or UE)
 
>    7.  The User extends their access through the web-portal via the UI

nits aside, this looks good to me.

> did it. The same trust as mentioned in section 7.1 still applies.

That sounds good, thanks.

>   that identifiers, if stored, are stored securely. Further,

Okay.  (This will not make people who are super-conscious about their
privacy happy, but I don't think we have room to do much more at this time.)

> AUTH option can sign this information."

Thanks!

> Does that sound reasonable?

That seems like it's in the right ballpark.  I guess both the API URI and
the web portal URI could be "unguessable" (though both would be protected
by the same TLS connection, at least for the UE/API part of things).

> describe that in a bit more detail?

The attack I had in mind did not involve exfiltrating information to the
attacker, just causing the UE to get confused (or miss updates, etc.).

> Correct on both accounts. Do you think we should clarify the intent?

I would like to say a little more here, yes.  There's a few ways we could
do it, ranging from talking about effectiveness of portal-detection to
discussion of what is common in captive portals at present.

> > nit: I suggest "these 'canary' requests" to clarify which requests we're

And thanks for the updates!

-Ben

---

From: Kyle Larose <[email-masked]>
Date: Sun, 14 Jun 2020 12:13:30 -0400

Inline again.

Note: I've clipped sections I'm not responding to.

> (unfortunately) a little prone to jargon.

I would definitely appreciate some help here. Thanks!

> That's a pretty good point; the association is more important than giving

Alright. I'll rephrase along the lines of my second suggestion about
association.

> privacy is a tricky area...

Thanks for the clarification.  I'll add some text along the lines of:

"Note that the User Equipment could force a change of the associated
identifier as part of a
workflow related to promoting privacy, though the mechanisms by which
it does so are out of
scope of the document."

> >    3.  The User Equipment's detects that the length of time left

Whoops. Thanks.

> (not sure if this is user or UE)

Since we're talking about devices with user interfaces, it should be the user.

New:
    6. The user accepts the prompt displayed by the user equipment.

> by the same TLS connection, at least for the UE/API part of things).

Tommy raised an objection in the issue
(https://github.com/capport-wg/architecture/issues/95) I submitted on
github for this. Initially,
I said that the API URI should be unguessable. I conflated the two
types of URI when I
wrote my initial reply. To clarify, I'm now planning only suggesting
that the user portal URI
be unguessable.

I'll repeat my earlier question: does anyone else have an opinion on
this? I feel like it could
be controversial, since it could add complexity to the solution, but I
do think it could help.

> attacker, just causing the UE to get confused (or miss updates, etc.).

Ah, I see. Thanks for the clarification: we don't discuss that the
rate limiting, while preventing the system from being
brought to its knees, could still cause a loss of information. How about:

".. limiting the impact of a repeated attack. However, note that if
the rate limit stops the UE from requesting information from the API
that it needs, particularly if there are multiple types of request the
UE could make to the API, then there is a chance that the UE could
lose information when under such an attack. The UE could take steps to
mitigate such an attack by rate limiting each type of request
individually."

I suppose we may also want to mention that if there are an unbounded,
or large number of types of request, then my above suggestion for a
mitigation may not suffice... Or do you think that's obvious?

> discussion of what is common in captive portals at present.

Robert brought up the lack of a problem statement for the document in
his review. We may choose to add that. If we do, I think we can
probably refer to that section here to clarify. Regarding what is
common in captive portals as present, perhaps rephrasing this bit to
point out that
the common UE implementation of detection is in response to the common
captive portal implementation of DNS modifications could
help to clarify.

Perhaps rephrasing to:
   ... Typical implementations use DNS over UDP, under the assumption that most
   existing captive portal implementations will only modify DNS over UDP, since
   queries over TCP or HTTPS are less likely to be modified than DNS
queries over
   UDP due to the complexity of implementation.

will do it?

Thanks again!

Kyle

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 15 Jun 2020 10:17:42 +1000

> wrote my initial reply. To clarify, I'm now planning only suggesting

The API URI being unguessable isn't really a worthwhile goal if every device that connects to the network will be handed the same value via RA.  Tommy's objection seems reasonable.

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 21 Jun 2020 11:51:01 -0700

Hi Kyle,

> I would definitely appreciate some help here. Thanks!

How about:

% If User Equipment supports the Captive Portal API, it MUST validate the
% API server's TLS Certificate according to the procedures in [RFC6125].
% The API server's URI is obtained via a network provisioning protocol,
% which will typically provide a hostname to be used in TLS server
% certificate validation, against a DNS-ID in the server certificate.  If
% the API server is identified by IP address, the iPAddress subjectAltName
% is used to validate the server certificate.

(The last sentence is optional.)

Thanks!

> > nits aside, this looks good to me.

(still looks good)

> wrote my initial reply. To clarify, I'm now planning only suggesting

That makes sense; there could be some value in having the API URI be
consistent (notably, in not having to track devices at as low a level), and
making it unique only starts adding value for the user-poral URI.

> be controversial, since it could add complexity to the solution, but I

Perhaps the chairs, at least, could weigh in?

> mitigation may not suffice... Or do you think that's obvious?

That might be more detail than the level of risk merits (and it's hopefully
obvious, too).

Thanks for adding the above discussion; it works for me.

>    UDP due to the complexity of implementation.

That should work, thanks.  It might be possible to wordsmith it down a
little bit more, but I don't have any ideas coming to mind at the moment.

Thanks for the updates!

-Ben

---

From: Erik Kline <[email-masked]>
Date: Sun, 21 Jun 2020 12:24:30 -0700

> Perhaps the chairs, at least, could weigh in?

I'm slightly unclear on what "unguessable" means in this context.  If
it means unique to a client, then the API URI should not be
per-client.  This is because the IPv6 RA option is multicasted to all
clients on the link and cannot reasonably be made per-client.

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 21 Jun 2020 14:39:01 -0700

> clients on the link and cannot reasonably be made per-client.

It's something stronger than unique per client, and yes, we're not going to
make the API URI unguessable.

Thanks for checking!

-Ben

---

From: Kyle Larose <[email-masked]>
Date: Tue, 23 Jun 2020 07:42:18 -0400

Hi Ben,

> (The last sentence is optional.)

That's excellent. Thanks!

> -Ben

Thanks again,

Kyle

---

From: [email-masked]
Date: Tue, 23 Jun 2020 08:30:37 -0400

Kyle, Ben,
One comment below.

> That's excellent. Thanks!

Looking at RFC6125 (section B.2), should we replace
"the iPAddress subjectAltName is used to validate the server 
certificate."
with,
"... the iPAddress subjectAltName must be present in the certificate and 
must
exactly match the IP address in the API server's URI."

> _______________________________________________
> Captive-portals mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/captive-portals

-Dave