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

From: Martin Duke via Datatracker <[email-masked]>
Date: Sat, 06 Jun 2020 14:49:19 -0700

Martin Duke has entered the following ballot position for
draft-ietf-capport-api-07: 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-api/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Unless I am misinterpreting the language here, there is a disconnect between
this document and the architecture document.

Sec 2.3 of -architecture 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 user-portal-url is an optional field. Is -architecture
actually levying a requirement on the api spec, or the api server?

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.”

Who is doing the redirecting here? If authentication has failed, how is this
redirect authenticated and secure against theft of credentials?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

This document is otherwise clearly written. Thanks.

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.”

One nit:
s/extenal/external

---

From: Tommy Pauly <[email-masked]>
Date: Sat, 06 Jun 2020 16:52:11 -0700

Hi Martin,

Thanks for the review. Responses inline. 

> On Jun 6, 2020, at 2:49 PM, Martin Duke via Datatracker <[email-masked]> 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. 

> redirect authenticated and secure against theft of credentials?

This is referring to the fact that the old HTTP redirect of a clear text webpage may still happen on a network. Even networks that support the API will need to handle legacy clients. This is only about redirecting unrelated pages to the user portal, and is orthogonal to the authenticity of the API server. 

User-portal is indeed the key name, representing the current use case of presenting a portal to a user. Other solutions in the future may use other URIs. In description text, we explain that this is a web portal page. I’d suggest using the user portal term in the architecture. 

> s/extenal/external

Good catch, will fix. 

Tommy

---

From: Martin Duke <[email-masked]>
Date: Sat, 6 Jun 2020 19:53:54 -0700

On Sat, Jun 6, 2020 at 4:52 PM Tommy Pauly <[email-masked]> 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.

> This is referring to the fact that the old HTTP redirect of a clear text
> webpage may still happen on a network. Even networks that support the API
> will need to handle legacy clients. This is only about redirecting
> unrelated pages to the user portal, and is orthogonal to the authenticity
> of the API server.
> >
>

Thank you for the clarification. I will move this bit to a COMMENT and
suggest “...access the network by redirecting a clear text webpage to a web
portal.”

---

From: Erik Kline <[email-masked]>
Date: Sun, 7 Jun 2020 17:03:16 -0700

On Sat, Jun 6, 2020 at 7:54 PM Martin Duke <[email-masked]> wrote:
> Very well, I’d like to hear from one of the chairs, but if confirmed I’m happy to move my DISCUSS to -architecture.

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

---

From: Kyle Larose <[email-masked]>
Date: Mon, 8 Jun 2020 08:20:23 -0400

> [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.

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 09 Jun 2020 11:17:29 +1000

On Sun, Jun 7, 2020, at 12:53, Martin Duke wrote:
> 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.