Subject: [Captive-portals] Roman Danyliw's No Objection on draft-ietf-capport-architecture-08: (with COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Tue, 09 Jun 2020 14:26:10 -0700

Roman Danyliw has entered the following ballot position for
draft-ietf-capport-architecture-08: No Objection

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/

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

I support Martin and Ben's DISCUSS positions.

Thanks for laying out the architecture to explain the subsequent protocol
drafts.  A few areas of feedback:

** Section 2.1. Per “At this time we consider …”, to what is “at this time”
referring (maybe this is referring to the WG scope)?  This might not age well
as currently framed.

** Section 2.2.  The architecture doesn’t explicitly describe which component
is responsibility for provisioning the user equipment sufficiently so it can
access the IP network anywhere.  I would have expected it to be the
Provisioning Service.  Section 2.1, 2.3 and 2.4 describe the role of these
components in the architecture and their requirements.  Section 2.2 does not. 
Instead it describes candidate technologies.  It would be helpful to explicitly
say.

** Section 2.3.  Perhaps this is too pedantic, but should the obvious be
explicitly called out: the user equipment should only be able to check it’s own
captivity status?  This would be some explicit notion of authorization.

** Section 2.3  Per “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.”, is the caller the User Equipment, the web browser or the end user –
does that distinction matter – does each layer need anything different?

** Section 3.2.1.  Per “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.”, is “unique among user equipment interacting at that
time” the same as saying “unique among the identifiers currently in use in the
Captive Network”?  It might be useful to frame this guidance within the scope
of the previous definitions.

** Section 3.2.2.  The acceptable workfactor for “hard” still isn’t clear here
but I understand the difficulty of pinning it down while remaining flexible.

** Section 4.  Does this section provide normative guidance?  The introductory
sentence suggests no by saying that this section describes “possible
workflow[s]”.  However, Section 4.3 uses a normative SHOULD.

** Section 4.2.  Between step #2 and #3, did some kind of signaling happen to
indicate that expiration is imminent, or did the UE keep state of some kind? 
Keeping state isn’t mentioned as a UE requirement in Section 2.1.  Section 2.5.
notes that a “signal might be generated when the end of a session is imminent”.

** Section 7.  This section would benefit from a discussion of the privacy
impacts of the implicit identifiers embedded into the architecture (e.g.,
re-identification)

** Section 7.1. Per “If a user decides to incorrectly trust an attacking
network ….”, you have an on-path attacker so additional risks include traffic
redirection to arbitrary destinations to server malicious payloads; traffic
analysis and loss of confidentiality; inline traffic modification; etc.

** Section 7.2.  Per “The solution described here assumes that when the User
Equipment needs to trust the API …”, why is this conditional.  Doesn’t the UE
have to trust the API server?

** Section 7.3.  In addition to integrity and confidentiality, is there an
authenticity requirement?  I ask because Section 2.1. noted that the UE “SHOULD
[be] allow[ed] access to any services that User Equipment could need to contact
to perform certificate validation.”

---

From: Kyle Larose <[email-masked]>
Date: Fri, 12 Jun 2020 09:59:27 -0400

Thanks Roman,

Responses inline

> draft-ietf-capport-architecture-08: No Objection

It is referring to the WG scope, but even that may not age well, I suppose.

How about just "This document only considers devices with ..."

> Instead it describes candidate technologies.  It would be helpful to explicitly

I didn't want to assume that the provisioning service was required for network
access (in case the network used a technology that allowed stateless access
somehow). But, it can't hurt to mention that in many cases the provisioning
service will be the component that does that. A suggested rephrasing of the
first paragraph of that section.

"The Provisioning Service is primarily responsible for providing a portal URI to
the User Equipment when it connects to the network, and later if the
URI changes.
The provisioning service could also be the same service which is responsible for
provisioning the User Equipment for access to the Captive Network
(e.g. by providing
it with an IP address). This section discusses two mechanisms which may be used
to provide the portal URI to the User Equipment.

It is expected that the provided URI will be for the API described in
Section 2.3".

> captivity status?  This would be some explicit notion of authorization.

I recall discussing this, but I don't think we settled on a good,
simple solution. I'm
fine pointing out that the user equipment should only be able to check its own
state of captivity, but I worry that discussing authorization will
open a large can
of worms. Do the chairs have an opinion on this?

> does that distinction matter – does each layer need anything different?

I don't think the distinction matters. This is intended to allow
whatever application
is running the captive portal workflow to make a decision based on the
response it
gets back. E.g.. if it's one the uE doesn't support, it could display
a notification to the user
indicating that there appears to be a captive network, but it is unsupported.

> of the previous definitions.
That is correct. I'll clarify by using your phrasing.

> workflow[s]”.  However, Section 4.3 uses a normative SHOULD.

It's meant to be informative. That statement likely belongs elsewhere.
I'll move it
to Section 2.1 (User Equipment)

> notes that a “signal might be generated when the end of a session is imminent”.

The implication is that there is state in this case -- the UE stored
the last response
it retrieved from the API so that it could consult the time remaining
(seconds-remaining
in the API document). I can update section 2.1 to indicate that the UE
could store information
from the API's response in order to trigger workflows related to
imminent expiry of its access.
Storing the state isn't required, but it could make the user
experience better if supported.

I plan on reworking section 4.2 in response to Benjamin's review. I'll
mention in it that the UE uses the stored information to make the
decision to remove the ambiguity.

> impacts of the implicit identifiers embedded into the architecture (e.g.,

Benjamin also pointed this out. I have started building up some text for this,
but it's a bit rough. Regarding re-identification, what are your
privacy concerns there?
The chance of a UE that once had an identifier masquerading as the new one using
information it was privy to at the time it was assigned it?

For what it's worth, here is my working text. It's pretty rough, and
likely needs elaboration.

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

> analysis and loss of confidentiality; inline traffic modification; etc.

We can update to mention those.

> have to trust the API server?

Hmm. I guess you could argue that it doesn't need to trust it if it
has chosen to not use it,
but I'm not sure that's relevant. Does anyone else have a good reason
to keep it conditional?

I need to expand on this section in response to Benjamin's
review. I'll change the phrasing so that  the trust is unconditional.

> to perform certificate validation.”

We definitely expect that the API server is the correct one. I figured
that the authenticity requirement
was covered in section 7.2 Should we combine the two sections?

Thanks!

Kyle

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 15 Jun 2020 09:44:28 +1000

> of worms. Do the chairs have an opinion on this?

This is a reasonable requirement to state, as it motivates the existing discussion of identifier selection.  A good part of the discussion we had around choosing identifiers was around the point of implicit identification and the potential for that to be spoofed.  That spoofing might circumvent authorization was largely implicit, but it doesn't hurt to be explicit.

Cheers,
Martin