I think there are two separate things here. [1] The use of HTTPS allows the client to authenticate the API and interactive URLs the same way a browser would be confident it's talking to amazon.com, for example.
I think in this sense, the text is correct. [2] There is, however, no way to know whether bobshouseofportals.example.com is the authoritative captive portal service for the MyCoffeeShop ESSID. We should have this explicitly stated somewhere. I couldn't quickly find such a section, but perhaps I should add some text about this to the 7710bis Security Considerations or thereabouts. On Sat, Jun 6, 2020 at 1:02 PM Rifaat Shekh-Yusef <rifaat.s.i...@gmail.com> wrote: > > Hi Tommy, > > You will probably need to do more than just dropping this specific sentence, > because the text just before this sentence talks about the client > authenticating the server and allowing the user to be confident of the server > and its identity. > > Regards, > Rifaat > > > On Tue, Jun 2, 2020 at 1:33 AM Tommy Pauly <tpa...@apple.com> wrote: >> >> Hi Rifaat, >> >> Your comments make it clear that the recommendation to make the API server >> name visible isn’t necessarily clear. I think it’s not a harmful thing to >> show, as a way to give troubleshooting information and transparency to the >> user, but it is not a security-critical point. >> >> It seems appropriate to either explain the rationale more in depth, or >> remove that sentence entirely to avoid the misinterpretation. >> >> Do others in the CAPPORT group have thoughts on this sentence, and any >> background on why we decided to go that way? Would there be any objections >> to removing the sentence? >> >> Thanks, >> Tommy >> >> On Jun 1, 2020, at 6:05 PM, Rifaat Shekh-Yusef <rifaat.s.i...@gmail.com> >> wrote: >> >> >> >> >> On Sun, May 31, 2020 at 2:07 AM Erik Kline <ek.i...@gmail.com> wrote: >>> >>> On Wed, May 20, 2020 at 4:37 AM Rifaat Shekh-Yusef >>> <rifaat.s.i...@gmail.com> wrote: >>> > >>> > Adding SecDir back to this thread. >>> > >>> > >>> > >Martin Thomson <m...@lowentropy.net> Tue, 19 May 2020 01:02 UTCShow >>> > >header >>> > > >>> > >On Tue, May 19, 2020, at 07:08, Rifaat Shekh-Yusef wrote: >>> > >> it provides the client of the API >>> > >> an opportunity to authenticate the server that is hosting the API. >>> > >> This authentication is aimed at *allowing a user to be reasonably >>> > >> confident that the entity providing the Captive Portal API has a >>> > >> valid certificate for the hostname in the URI* >>> > >[...] >>> > >> An end user should be able to validate that the name is example.com and >>> > >> not any other form of the URI. >>> > >> It would be much more difficult for the end user to make sense and >>> > >> validate an IP address. >>> > > >>> > >I think that you missed the point of my comments. This validation, >>> > >performed by >>> > >a user, has no meaningful security value. The text you cite says that >>> > >the server >>> > >has a certificate for the name it chooses, which is not the same as "has >>> > >a certificate >>> > >for a name the client expects". The difference is important. >>> > > >>> > >>> > This is not the way I read these statements from section 4.1 titled >>> > Server Authentication. >>> > >>> > Here is the use case I have in mind when I read this section: >>> > If I walk into an airport and I see an ad for a paid Internet service >>> > from example.com, then as an >>> > end user it is reasonable to expect that I would have some ability to >>> > make sense of the name >>> > presented to me and make sure it is from example.com if I choose to get >>> > such a service. >>> > >>> > If this is not the case, then yo might want to make it clear that this is >>> > not about Server Authentication >>> > as the title of the section and the text inside that section is >>> > suggesting. >>> >>> If we changed the API document's section 4.1 title from "Server >>> Authentication" to "API Server Authentication", would that be more >>> clear? >>> >>> I reality, users should never see the API URL. >> >> >> The following is a quote from section 4.1 of the API document, which implies >> otherwise: >> "The hostname of the API SHOULD be displayed to the user in order to >> indicate the entity which is providing the API service." >> >> Regards, >> Rifaat >> >> >> >>> >>> They'll just be >>> connecting to "Cool Cafe" or "Awesome Bookshop" ESSIDs. If anything >>> will only be one or both of the "user-portal-url" or "venue-info-url" >>> URLs that might be visible in the browser that's opened for the user's >>> interaction. >>> >>> -ek >>> >>> > Regards, >>> > Rifaat >>> > >>> > >>> > >>> > >In a typical web scenario, a person types a string in and (ignore the >>> > >case where there >>> > >is an extra hop via a search engine) that string determines what is >>> > >acceptable as a >>> > >server identity. The exposure to confusables is limited (under a set of >>> > >other assumptions, >>> > >HSTS, etc...). Here, the network has free reign to do as they choose >>> > >with homoglyphs and >>> > >other such nonsense. Any expectation you might have about this really >>> > >being a trustworthy >>> > >entity is meaningless in this context. >>> > > >>> > >There are protections against this, but they all lie firmly in the >>> > >anti-phishing domain. >>> > >Most of those rely on having a certificate though, so the requirement >>> > >for HTTPS is in >>> > >service of that, not in terms of ensuring that an untrained human can >>> > >make a security >>> > >critical decision based on poisoned information. >>> > >>> > On Mon, May 18, 2020 at 5:08 PM Rifaat Shekh-Yusef >>> > <rifaat.s.i...@gmail.com> wrote: >>> >> >>> >> Adding Ben. >>> >> >>> >> >>> >> On Sun, May 17, 2020 at 9:26 PM Martin Thomson <m...@lowentropy.net> >>> >> wrote: >>> >>> >>> >>> Adding more lists.. >>> >>> >>> >>> On Sun, May 17, 2020, at 02:50, Rifaat Shekh-Yusef wrote: >>> >>> > > Here is a quote form the API document: >>> >>> > > "The hostname of the API SHOULD be displayed to the user in order >>> >>> > > to indicate the entity which is providing the API service." >>> >>> > > >>> >>> > > This seems to suggest that the user is expected to inspect the >>> >>> > > displayed name and make sure it is make sense in the context of >>> >>> > > whoever is providing that service. >>> >>> >>> >>> I don't think that is the case. If this were a security mechanism, >>> >>> then it would use "MUST". This is likely for the purpose of enabling >>> >>> some sort of accountability. In other words, this is to offer maximal >>> >>> information about what is going on. >>> >>> >>> >> Here is the sentence just before the above quote from the API document: >>> >> >>> >> it provides the client of the API >>> >> an opportunity to authenticate the server that is hosting the API. >>> >> This authentication is aimed at allowing a user to be reasonably >>> >> confident that the entity providing the Captive Portal API has a >>> >> valid certificate for the hostname in the URI >>> >> >>> >> >>> >> >>> >> >>> >>> >>> >>> > > Since this would be an easier attack compared to the interception >>> >>> > > attack, and IP address is still permitted, then an attacker might >>> >>> > > force the use of IP address to make it harder for the user to make >>> >>> > > sense of the displayed name. >>> >>> >>> >>> I don't think that is materially different than getting a name with >>> >>> confusable characters (or using the prefix hack, >>> >>> example.com.<some-guid>.example, in an attempt to confuse). >>> >> >>> >> >>> >> An end user should be able to validate that the name is example.com and >>> >> not any other form of the URI. >>> >> It would be much more difficult for the end user to make sense and >>> >> validate an IP address. >>> >> >>> >> Regards, >>> >> Rifaat >>> >> >>> > _______________________________________________ >>> > Captive-portals mailing list >>> > Captive-portals@ietf.org >>> > https://www.ietf.org/mailman/listinfo/captive-portals _______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
