Hi Ben,
On Sun, 21 Jun 2020 at 14:51, Benjamin Kaduk <ka...@mit.edu> wrote: > > Hi Kyle, > > On Sun, Jun 14, 2020 at 12:13:30PM -0400, Kyle Larose wrote: > > Inline again. > > > > Note: I've clipped sections I'm not responding to. > > > > On Fri, 12 Jun 2020 at 20:50, Benjamin Kaduk <ka...@mit.edu> wrote: > > > > > > Also inline. > > > > > > On Thu, Jun 11, 2020 at 09:12:34AM -0400, Kyle Larose wrote: > > > > Hi Benjamin, > > > > > > > > > > > > > > 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). > > > > > > > > We can do this. > > > > > > Please feel free to reach out if you want advice on text to put here; it's > > > (unfortunately) a little prone to jargon. > > > > 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.) > That's excellent. Thanks! > > > > > > > > > > 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. > > > > > > > > > > > > > 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?" > > > > > > That's a pretty good point; the association is more important than giving > > > or assignment. > > > > Alright. I'll rephrase along the lines of my second suggestion about > > association. > > > > > > > > > > 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... > > > > > > > > > > > > > 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? > > > > > > 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... > > > > > > > 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." > > Thanks! > > > > > > > > > > > 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.) > > > > > > > > > > > > > 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 > > > > > > (nit: s/'s//) > > > > Whoops. Thanks. > > > > > > > > > for its access has fallen below a threshold > > > > > > > > 4. The User Equipment visits the API again to validate the expiry > > > > time > > > > > > > > 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 > > > > > > (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. > > > > > > 7. The User extends their access through the web-portal via the UI > > > > > > nits aside, this looks good to me. > > (still looks good) > > > > > > > > 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? > > > > > > > > > > > > > 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? > > > > > > 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). > > > > > > > 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. > > 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. > > > 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. > > Perhaps the chairs, at least, could weigh in? > > > > > > 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. > > > > > > > > > > > > > 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? > > > > > > 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.). > > > > > > > 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? > > 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. > > > > > > > > > > Section 8.1 > > > > > > > > > > > > > > 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.) > > > > > > > > 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. > > > > > > > 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? > > 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 Thanks again, Kyle _______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
