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

Tommy Pauly <> Sat, 06 June 2020 23:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B86DC3A0795; Sat, 6 Jun 2020 16:52:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HBDdR6kEDTzv; Sat, 6 Jun 2020 16:52:16 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 124533A0793; Sat, 6 Jun 2020 16:52:15 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id 056Np8Qf038466; Sat, 6 Jun 2020 16:52:13 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=content-type : content-transfer-encoding : mime-version : subject : from : in-reply-to : cc : date : message-id : references : to; s=20180706; bh=lOAaPpJXQdQjfE6s0W2MB4zsmXnVUP1tLYayAfR3ym4=; b=PbgMqrOWUE/Ce4xhLfB3fu3MjJ5Lra2OFrz31WBBJyOIIAy+oySFw5G85rhy3Kte251X flbQBzidzBAoCgxRf8AEM4xP9eqdedrlu+7iMgl2Y0e0TDwamORPGygNfQC44g8lz8Y0 o3ECS3QXtXSeiVspezSLlQb/TIeWUW3wiKeZ0kkUy9R0q733qDDCzdSZ/Z4zHh6z4eT+ vAtr41x1aBP/nEyGWBVLMairqIAEzTiPYkV55utLv11VDYYXYcdnqrDnuqTnHt3s38h+ 1snF7ZcWYc0hrbMeoVxpjqfAQYEIYAh/1uaCywin61GRH3KcYHMp4t0TNLg/aSD9xlr5 ng==
Received: from ( []) by with ESMTP id 31g9t1ybmq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 06 Jun 2020 16:52:13 -0700
Received: from ( []) by (Oracle Communications Messaging Server 64bit (built Mar 12 2020)) with ESMTPS id <>; Sat, 06 Jun 2020 16:52:13 -0700 (PDT)
Received: from by (Oracle Communications Messaging Server 64bit (built Mar 12 2020)) id <>; Sat, 06 Jun 2020 16:52:13 -0700 (PDT)
X-Va-T-CD: 45f18851fe00c2da7ad83c72970c512e
X-Va-E-CD: b8935aba4646f1ade82671f34f404541
X-Va-R-CD: 53d635e4b76b53743bb0ff0dd1a0c52d
X-Va-CD: 0
X-Va-ID: 67d1f625-8770-497f-8b15-ef53ca00398d
X-V-T-CD: 45f18851fe00c2da7ad83c72970c512e
X-V-E-CD: b8935aba4646f1ade82671f34f404541
X-V-R-CD: 53d635e4b76b53743bb0ff0dd1a0c52d
X-V-CD: 0
X-V-ID: d8fd145a-21c9-4779-9867-913d0114571c
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-06_20:2020-06-04, 2020-06-06 signatures=0
Received: from [] (unknown []) by (Oracle Communications Messaging Server 64bit (built Mar 12 2020)) with ESMTPSA id <>; Sat, 06 Jun 2020 16:52:13 -0700 (PDT)
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: quoted-printable
MIME-version: 1.0 (1.0)
From: Tommy Pauly <>
In-reply-to: <>
Cc: The IESG <>,,,, Martin Thomson <>,
Date: Sat, 06 Jun 2020 16:52:11 -0700
Message-id: <>
References: <>
To: Martin Duke <>
X-Mailer: iPhone Mail (18A306)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-06_20:2020-06-04, 2020-06-06 signatures=0
Archived-At: <>
Subject: Re: [Captive-portals] Martin Duke's Discuss on draft-ietf-capport-api-07: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of issues related to captive portals <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 06 Jun 2020 23:52:18 -0000

Hi Martin,

Thanks for the review. Responses inline. 

> On Jun 6, 2020, at 2:49 PM, Martin Duke via Datatracker <> wrote:
> 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
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> 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 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. 

> 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?

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

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. 

> One nit:
> s/extenal/external

Good catch, will fix.