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.
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.
> ----------------------------------------------------------------------
> 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 =-
signature.asc
Description: PGP signature
_______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
