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

[Kyle Larose <[e-mail]>]

Thanks Roman,

Responses inline

On Tue, 9 Jun 2020 at 17:26, Roman Danyliw via Datatracker
<[e-mail]> wrote:
>
> Roman Danyliw has entered the following ballot position for
> draft-ietf-capport-architecture-08: No Objection
>
>
> ----------------------------------------------------------------------
> 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.
>

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

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

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


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

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?

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

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.


> ** 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.
>
That is correct. I'll clarify by using your phrasing.

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

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

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

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.

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

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



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

We can update to mention those.

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

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.


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

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