Re: [Captive-portals] Secdir last call review of draft-ietf-capport-rfc7710bis-04
On Sun, Jun 7, 2020 at 8:21 PM Erik Kline wrote: > 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. > > The client would not be able to validate the server identity without the help of the end user, because an attacker could inject DHCP messages to force the client to contact an attacker controlled server. The text explicitly states that the end user is expected to be involved, but some of the replies I received in this thread indicate otherwise. When you say "the text is correct", do you include the user involvement? > [2] There is, however, no way to know whether > bobshouseofportals.example.com is the authoritative captive portal > service for the MyCoffeeShop ESSID. > > Assuming that the client was able to validate the API server's identity in the previous step, would the client not be able to obtain all the needed information to validate the web portal server? Regards, Rifaat > 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 > 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 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 > wrote: > >> > >> > >> > >> > >> On Sun, May 31, 2020 at 2:07 AM Erik Kline wrote: > >>> > >>> On Wed, May 20, 2020 at 4:37 AM Rifaat Shekh-Yusef > >>> wrote: > >>> > > >>> > Adding SecDir back to this thread. > >>> > > >>> > > >>> > >Martin Thomson 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." >
Re: [Captive-portals] Secdir last call review of draft-ietf-capport-rfc7710bis-04
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 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 > wrote: > > > > > On Sun, May 31, 2020 at 2:07 AM Erik Kline wrote: > >> On Wed, May 20, 2020 at 4:37 AM Rifaat Shekh-Yusef >> wrote: >> > >> > Adding SecDir back to this thread. >> > >> > >> > >Martin Thomson 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 >> 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
Re: [Captive-portals] Secdir last call review of draft-ietf-capport-rfc7710bis-04
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 > wrote: > > > > >> On Sun, May 31, 2020 at 2:07 AM Erik Kline wrote: >> On Wed, May 20, 2020 at 4:37 AM Rifaat Shekh-Yusef >> wrote: >> > >> > Adding SecDir back to this thread. >> > >> > >> > >Martin Thomson 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 >> > wrote: >> >> >> >> Adding Ben. >> >> >> >> >> >> On Sun, May 17, 2020 at 9:26 PM Martin Thomson >> >> 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
Re: [Captive-portals] Secdir last call review of draft-ietf-capport-rfc7710bis-04
On Sun, May 31, 2020 at 2:07 AM Erik Kline wrote: > On Wed, May 20, 2020 at 4:37 AM Rifaat Shekh-Yusef > wrote: > > > > Adding SecDir back to this thread. > > > > > > >Martin Thomson 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 > 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
Re: [Captive-portals] Secdir last call review of draft-ietf-capport-rfc7710bis-04
Adding SecDir back to this thread. >Martin Thomson 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. 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 wrote: > Adding Ben. > > > On Sun, May 17, 2020 at 9:26 PM Martin Thomson 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..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
Re: [Captive-portals] Secdir last call review of draft-ietf-capport-rfc7710bis-04
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. 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. ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] Secdir last call review of draft-ietf-capport-rfc7710bis-04
Adding Ben. On Sun, May 17, 2020 at 9:26 PM Martin Thomson 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..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
Re: [Captive-portals] Secdir last call review of draft-ietf-capport-rfc7710bis-04
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. > > 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..example, in an attempt to confuse). ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] Secdir last call review of draft-ietf-capport-rfc7710bis-04
Perhaps a reference to https://tools.ietf.org/html/rfc3756 as well as the security considerations sections of 2131, 4861, 4862, and 8415. I'm capturing notes in https://github.com/capport-wg/7710bis/issues/30 . On Sun, 3 May 2020 at 17:09, Martin Thomson wrote: > I think that the standard assumption is that we can equate the ability to > send a DHCP response or a RA with control of the network (or at least those > aspects of the network upon which clients rely on DHCP/RA for). I don't > know if that assumption is written down in a place we could cite it, but if > it were, I would suggest a citation. > > On Mon, May 4, 2020, at 07:58, Erik Kline wrote: > > Rifaat, > > > > Thanks for your reading of the document. > > > > The security section has a paragraph that begins: > > > > """ > > An attacker with the ability to inject DHCP messages or RAs could > > include an option from this document to force users to contact an > > address of his choosing. As an attacker with this capability could > > simply list himself as the default gateway (and so intercept all the > > victim's traffic); this does not provide them with significantly more > > capabilities, but because this document removes the need for > > interception, the attacker may have an easier time performing the > > attack > > """ > > > > Do you have any specific ideas for what text might be added to clarify > > vis. your concern? Would a sentence that captures your "the use of TLS > > and presenting the identity in the certificate might not be of much > > help" observation suffice? > > > > Thanks, > > -Erik > > > > On Fri, 1 May 2020 at 05:10, Rifaat Shekh-Yusef via Datatracker > > wrote: > > > Reviewer: Rifaat Shekh-Yusef > > > Review result: Has Issues > > > > > > Since the use of IP address literal is not forbidden by this > document, what if > > > an attacker with the ability to inject DHCP messages or RAs uses this > option > > > to force the user to contact an IP address of his choosing? In this > case, the use > > > of TLS and presenting the identity in the certificate might not be of > much help. > > > > > > I think this case should be discussed in the security consideration > section.. > > > > > > > > ___ > > 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 > ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] Secdir last call review of draft-ietf-capport-rfc7710bis-04
I think that the standard assumption is that we can equate the ability to send a DHCP response or a RA with control of the network (or at least those aspects of the network upon which clients rely on DHCP/RA for). I don't know if that assumption is written down in a place we could cite it, but if it were, I would suggest a citation. On Mon, May 4, 2020, at 07:58, Erik Kline wrote: > Rifaat, > > Thanks for your reading of the document. > > The security section has a paragraph that begins: > > """ > An attacker with the ability to inject DHCP messages or RAs could > include an option from this document to force users to contact an > address of his choosing. As an attacker with this capability could > simply list himself as the default gateway (and so intercept all the > victim's traffic); this does not provide them with significantly more > capabilities, but because this document removes the need for > interception, the attacker may have an easier time performing the > attack > """ > > Do you have any specific ideas for what text might be added to clarify > vis. your concern? Would a sentence that captures your "the use of TLS > and presenting the identity in the certificate might not be of much > help" observation suffice? > > Thanks, > -Erik > > On Fri, 1 May 2020 at 05:10, Rifaat Shekh-Yusef via Datatracker > wrote: > > Reviewer: Rifaat Shekh-Yusef > > Review result: Has Issues > > > > Since the use of IP address literal is not forbidden by this document, > > what if > > an attacker with the ability to inject DHCP messages or RAs uses this > > option > > to force the user to contact an IP address of his choosing? In this case, > > the use > > of TLS and presenting the identity in the certificate might not be of much > > help. > > > > I think this case should be discussed in the security consideration > > section.. > > > > > ___ > 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
[Captive-portals] Secdir last call review of draft-ietf-capport-rfc7710bis-04
Reviewer: Rifaat Shekh-Yusef Review result: Has Issues Since the use of IP address literal is not forbidden by this document, what if an attacker with the ability to inject DHCP messages or RAs uses this option to force the user to contact an IP address of his choosing? In this case, the use of TLS and presenting the identity in the certificate might not be of much help. I think this case should be discussed in the security consideration section. ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
