Responses inline On Tue, 9 Jun 2020 at 12:27, Michael Richardson <mcr+i...@sandelman.ca> wrote: > > Benjamin Kaduk via Datatracker <nore...@ietf.org> wrote: > > (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? > > 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. >
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? > 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. > Yes, this was the motivation. > > > ---------------------------------------------------------------------- > > 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? > > 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 <mcr+i...@sandelman.ca>, Sandelman Software Works > -= IPv6 IoT consulting =- > > > Thanks, Kyle _______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
