Re: [Captive-portals] Martin Duke's Discuss on draft-ietf-capport-api-07: (with DISCUSS and COMMENT)

[Martin Thomson]

On Sun, Jun 7, 2020, at 12:53, Martin Duke wrote:
> 
> 
> On Sat, Jun 6, 2020 at 4:52 PM Tommy Pauly  wrote:
> > 
> > 
> >  I believe in this case the architecture document needs to change, or 
> > clarify that this MUST refers to that the mechanism needs to be *able* to 
> > communicate such a URI, not that such a URI must always be communicated.
> > 
> >  The group has discussed this several times, and I believe the API doc 
> > reflects the consensus: while we aren’t tackling solutions for captive 
> > portals that don’t involve User Portal pages (future solutions using a more 
> > OS-driven experience and perhaps built in payment, etc), we want to allow 
> > the API JSON to be usable in those new models. Not all captive networks 
> > will necessarily use this kind of URI in the future, and there’s no need to 
> > make the registry lock that in as mandatory. 
> 
> Very well, I’d like to hear from one of the chairs, but if confirmed 
> I’m happy to move my DISCUSS to -architecture.

I can confirm that Tommy's recollection is correct.  There are cases where 
captivity is not negotiable - well at least not using a web browser.  I think 
that we just didn't capture this very well in the architecture doc.

___
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

[Rifaat Shekh-Yusef]

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] Murray Kucherawy's No Objection on draft-ietf-capport-architecture-08: (with COMMENT)

[Murray S. Kucherawy]

On Mon, Jun 8, 2020 at 5:33 AM Kyle Larose  wrote:
> > Also curious is that "User Equipment" is defined in Section 2.1, but not
> > shortened to "UE" anywhere other than in Section 3.5.
> >
>
> We should be consistent throughout the document. If it aids
> readability, I have no problem changing it to UE. Do you think that
> would help?

Actually since there's only "UE" present in the one section, I would
simply expand it there so it matches the rest of the document.

> > In Section 4.1, what's an "RA"?
> >
> >
>
> Router Advertisement (rfc4861). This section is discussing workflows
> related to https://tools.ietf.org/html/draft-ietf-capport-rfc7710bis-02,
> which describes how router advertisements would be used in more
> detail.
>
> I suppose using the full term here would help clarify, though there is
> also an opportunity to reference rfc4861 -- I'm not sure whether
> that's necessary, since presumably someone seeking further
> clarification would read rfc7710bis, which references rfc4861. I'm
> happy to add the reference if you think it's necessary.

Either.  I just meant the acronym is introduced but not defined
anywhere.  Even saying "RA (Router Advertisement)" would be an
improvement, but a citation is also a great idea.

-MSK

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] Martin Duke's No Objection on draft-ietf-capport-api-07: (with COMMENT)

[Martin Duke]

Thanks!

On Mon, Jun 8, 2020 at 8:50 AM Tommy Pauly  wrote:

> Hi Martin,
>
> Thanks for the updated review. I’ve incorporated these comments in our
> GitHub:
>
>
> https://github.com/capport-wg/api/commit/daeba897a1d50229b86f6ec23a026aaa725bf672
>
> Thanks,
> Tommy
>
> On Jun 8, 2020, at 8:08 AM, Martin Duke via Datatracker 
> wrote:
>
> Martin Duke has entered the following ballot position for
> draft-ietf-capport-api-07: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-capport-api/
>
>
>
> --
> COMMENT:
> --
>
> This document is clearly written. Thanks.
>
> I am also confused by this sentence at the end of section 4.1 about failed
> authentication: “It may still be possible for the user to access the
> network by
> being redirected to a web portal.”
>
> I suggest “...access the network by redirecting a clear text webpage to a
> web
> portal.”  I was a bit confused by the original wording.
>
> As I said in the architecture review, the term for the user portal keeps
> changing. Over there it’s called a “Captive Portal Server” and a “web
> portal
> server”. Here it’s a “user-portal.” The authors of the two docs should get
> together and agree on a term.
>
> One nit:
> s/extenal/external
>
>
>
>
>
___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] Murray Kucherawy's No Objection on draft-ietf-capport-api-07: (with COMMENT)

[Tommy Pauly]

Hi Murray,

Thanks for the review! Some comments inline.

> On May 13, 2020, at 12:45 AM, Murray Kucherawy via Datatracker 
>  wrote:
> 
> Murray Kucherawy has entered the following ballot position for
> draft-ietf-capport-api-07: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-capport-api/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Nice work.
> 
> A couple of points on the IANA registrations:
> 
> Section 8.1: The "Interoperability Considerations" text isn't quite what I
> think is anticipated by RFC 6838.  Given what you're saying there against what
> Section 6.2 of that document says, I think you could just have "None" here, 
> but
> either way I suggest it's worth a second look.

This is boilerplate text that we lifted from other RFCs with similar forms (RFC 
8460, RFC 8427). I’m fine with this being “None” as well, if that’s the general 
guidance.
> 
> Section 8.2: I suggest either having a column dedicated to recording the
> specification (since the Designated Expert is supposed to ensure there is 
> one),
> or explicitly encourage that it be referenced in the Description column.

That's a great point. I’ve added this to our working copy in GitHub:

https://github.com/capport-wg/api/commit/67fe784f0cb2883367a46da740378338ecf84805
 


Thanks,
Tommy
> 
> 
> 

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] Martin Duke's No Objection on draft-ietf-capport-api-07: (with COMMENT)

[Tommy Pauly]

Hi Martin,

Thanks for the updated review. I’ve incorporated these comments in our GitHub:

https://github.com/capport-wg/api/commit/daeba897a1d50229b86f6ec23a026aaa725bf672
 


Thanks,
Tommy

> On Jun 8, 2020, at 8:08 AM, Martin Duke via Datatracker  
> wrote:
> 
> Martin Duke has entered the following ballot position for
> draft-ietf-capport-api-07: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-capport-api/
> 
> 
> 
> --
> COMMENT:
> --
> 
> This document is clearly written. Thanks.
> 
> I am also confused by this sentence at the end of section 4.1 about failed
> authentication: “It may still be possible for the user to access the network 
> by
> being redirected to a web portal.”
> 
> I suggest “...access the network by redirecting a clear text webpage to a web
> portal.”  I was a bit confused by the original wording.
> 
> As I said in the architecture review, the term for the user portal keeps
> changing. Over there it’s called a “Captive Portal Server” and a “web portal
> server”. Here it’s a “user-portal.” The authors of the two docs should get
> together and agree on a term.
> 
> One nit:
> s/extenal/external
> 
> 
> 

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] Martin Duke's No Objection on draft-ietf-capport-architecture-08: (with COMMENT)

[Martin Duke]

Thanks Kyle. I had to move this to a DISCUSS based on the
inconsistent requirements with -api, but it sounds like this is about to be
resolved.

On Mon, Jun 8, 2020 at 5:05 AM Kyle Larose  wrote:

> Hi Martin,
>
> Thanks for the review!
>
> Responses inline
>
> On Sat, 6 Jun 2020 at 01:49, Martin Duke via Datatracker
>  wrote:
> >
> > Martin Duke has entered the following ballot position for
> > draft-ietf-capport-architecture-08: No Objection
> >
>
> >
> > --
> > COMMENT:
> > --
> >
> > I found the terminology around “Captive Portal API server” and “Captive
> Portal
> > Server” to be a little confusing, as these are similar terms. The latter
> also
> > doesn’t get its own discussion in Section 2 and is confusingly called
> the “web
> > portal server” in Figure 1.
> >
>
>
> The Captive Portal API Server is the server hosting the Captive Portal
> API. The Captive Portal Server is the server hosting the page(s) used
> to communicate with the user visually via some form of client.
>
> I think, given your comments in the API review, and of the other
> working group members who commented there, that we should use Tommy's
> suggestion of "User Portal" in place of Captive Portal Server. That
> should hopefully remove any confusion caused by the similarity between
> the two terms.
>
> > After Figure 1, this seems to be consistently called the “web portal”
> (sec 2.6
> > and 4). It would be great to unify the terminology across the document
> as a
> > whole.
> >
>
> I agree. That's a mistake; the document should be consistent. We'll fix
> that up.
>
> Thanks!
>
> Kyle
>
___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

[Captive-portals] Martin Duke's No Objection on draft-ietf-capport-api-07: (with COMMENT)

[Martin Duke via Datatracker]

Martin Duke has entered the following ballot position for
draft-ietf-capport-api-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-capport-api/



--
COMMENT:
--

This document is clearly written. Thanks.

I am also confused by this sentence at the end of section 4.1 about failed
authentication: “It may still be possible for the user to access the network by
being redirected to a web portal.”

I suggest “...access the network by redirecting a clear text webpage to a web
portal.”  I was a bit confused by the original wording.

As I said in the architecture review, the term for the user portal keeps
changing. Over there it’s called a “Captive Portal Server” and a “web portal
server”. Here it’s a “user-portal.” The authors of the two docs should get
together and agree on a term.

One nit:
s/extenal/external



___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

[Captive-portals] Martin Duke's Discuss on draft-ietf-capport-architecture-08: (with DISCUSS and COMMENT)

[Martin Duke via Datatracker]

Martin Duke has entered the following ballot position for
draft-ietf-capport-architecture-08: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-capport-architecture/



--
DISCUSS:
--

Sec 2.3  says:
At minimum, the API MUST provide: (1) the state of captivity and (2) a URI for
the Captive Portal Server.

But in section 5 of capport-api, user-portal-url is an optional field.

Both a capport-api author and a WG chair agreed that the architecture doc
should be fixed, so I'm moving the DISCUSS here.


--
COMMENT:
--

I found the terminology around “Captive Portal API server” and “Captive Portal
Server” to be a little confusing, as these are similar terms. The latter also
doesn’t get its own discussion in Section 2 and is confusingly called the “web
portal server” in Figure 1.

After Figure 1, this seems to be consistently called the “web portal” (sec 2.6
and 4). In the API doc it is called a "user portal." It would be great to unify
the terminology across the documents as a whole.



___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] Murray Kucherawy's No Objection on draft-ietf-capport-architecture-08: (with COMMENT)

[Kyle Larose]

Hi Murray,

Thanks for the review!

Responses inline.

On Sun, 7 Jun 2020 at 00:00, Murray Kucherawy via Datatracker
 wrote:
>
> Murray Kucherawy has entered the following ballot position for
> draft-ietf-capport-architecture-08: No Objection
>
> --
> COMMENT:
> --
>
> Pretty straightforward.  Looking forward to the API document.
>
> Some nits:
>
> Although I see why you did it, the capitalization of the bullet list in 
> Section
> 3.2 appears peculiar.
>

You're correct. I think the latter three bullets break the
construction anyway, since they don't directly match the titles of the
sections. We'll fix this up.

> Also curious is that "User Equipment" is defined in Section 2.1, but not
> shortened to "UE" anywhere other than in Section 3.5.
>

We should be consistent throughout the document. If it aids
readability, I have no problem changing it to UE. Do you think that
would help?

> In Section 4.1, what's an "RA"?
>
>

Router Advertisement (rfc4861). This section is discussing workflows
related to https://tools.ietf.org/html/draft-ietf-capport-rfc7710bis-02,
which describes how router advertisements would be used in more
detail.

I suppose using the full term here would help clarify, though there is
also an opportunity to reference rfc4861 -- I'm not sure whether
that's necessary, since presumably someone seeking further
clarification would read rfc7710bis, which references rfc4861. I'm
happy to add the reference if you think it's necessary.

Thanks!

Kyle

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] Martin Duke's Discuss on draft-ietf-capport-api-07: (with DISCUSS and COMMENT)

[Kyle Larose]

On Sun, 7 Jun 2020 at 20:03, Erik Kline  wrote:

>
> Tommy is correct.  I think the architecture document should add a
> qualifying subclause to clarify that requirement (2) only applies "if
> captive portal enforcement may be active on the given network" or
> something.
>
> The model supports, for example, the very experiment we ran on the
> IETF 106 network [106EXP].  In that experiment we handed out an API
> URI via 7710/7710bis mechanisms to an API that told the client it was
> /not/ captive but that a venue-info-url was available (which led to a
> service that redirected clients to the agenda page, IIRC).
>
> [106EXP] https://tickets.meeting.ietf.org/wiki/CAPPORT

Indeed, this inconsistency was brought up earlier
(https://mailarchive.ietf.org/arch/msg/captive-portals/FfPC0M6Plmflg5G92uylDn2stH4/).
There's an issue
(https://github.com/capport-wg/architecture/issues/71) opened against
the architecture regarding it. Let's fix it there by making it
optional.

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] Martin Duke's No Objection on draft-ietf-capport-architecture-08: (with COMMENT)

[Kyle Larose]

Hi Martin,

Thanks for the review!

Responses inline

On Sat, 6 Jun 2020 at 01:49, Martin Duke via Datatracker
 wrote:
>
> Martin Duke has entered the following ballot position for
> draft-ietf-capport-architecture-08: No Objection
>

>
> --
> COMMENT:
> --
>
> I found the terminology around “Captive Portal API server” and “Captive Portal
> Server” to be a little confusing, as these are similar terms. The latter also
> doesn’t get its own discussion in Section 2 and is confusingly called the “web
> portal server” in Figure 1.
>


The Captive Portal API Server is the server hosting the Captive Portal
API. The Captive Portal Server is the server hosting the page(s) used
to communicate with the user visually via some form of client.

I think, given your comments in the API review, and of the other
working group members who commented there, that we should use Tommy's
suggestion of "User Portal" in place of Captive Portal Server. That
should hopefully remove any confusion caused by the similarity between
the two terms.

> After Figure 1, this seems to be consistently called the “web portal” (sec 2.6
> and 4). It would be great to unify the terminology across the document as a
> whole.
>

I agree. That's a mistake; the document should be consistent. We'll fix that up.

Thanks!

Kyle

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals