Thanks Roman, Responses inline
On Tue, 9 Jun 2020 at 17:26, Roman Danyliw via Datatracker <nore...@ietf.org> 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 _______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
