Re: [Captive-portals] Capport return of experience and... questions :(

[Martin Thomson]

On Mon, Jul 18, 2022, at 17:37, Michael Richardson wrote:
> I'm hoping we'll find soneone replying here about this, perhaps offering to
> debug this with you.  (This might be a job for the IETF Hackathon
> VPN... which does L2 stuff)

Tommy probably knows what is going on.  Or at least can help with working it 
out.

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

[Captive-portals] Fwd: [rfc-i] Document Action: Comcast's Web Notification System Design to Historic

[Martin Thomson]

This news might be of interest here.

- Original message -
From: "RFC ISE (Adrian Farrel)" 
To: rfc-inter...@rfc-editor.org
Subject: [rfc-i] Document Action: Comcast's Web Notification System Design to 
Historic
Date: Saturday, March 20, 2021 03:19

The ISE has approved changing the status of the following document:
- Comcast's Web Notification System Design (RFC 6108) to Historic

This document action is documented at:
https://datatracker.ietf.org/doc/RFC6108/History

A URL of the affected document is:
https://datatracker.ietf.org/doc/rfc6108/

Status Change Details:

RFC 6018 was published as an Informational RFC in the Independent
Submissions Stream.

This RFC documents a method of providing critical end-user notifications
to web browsers, which was deployed by Comcast,

One of the authors (who still has affiliation with Comcast) has confirmed
that Comcast no longer uses this system and it has been withdrawn from the
field. The author requested that the document status be changed to
Historic.

Personnel

   Adrian Farrel is the Independent Submissions Editor.


-- 
Adrian Farrel (ISE),
rfc-...@rfc-editor.org

___
rfc-interest mailing list
rfc-inter...@rfc-editor.org
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

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

Re: [Captive-portals] RFC 8952 on Captive Portal Architecture

[Martin Thomson]

Hey everyone,

Join me in thanking the editors of the new RFC.  This was good work.

I'll be talking to Barry now about formally closing the group.  We'll leave 
this list open in case people want to continue to discuss new work on this 
topic.

On Tue, Dec 1, 2020, at 13:51, rfc-edi...@rfc-editor.org wrote:
> A new Request for Comments is now available in online RFC libraries.
> 
> 
> RFC 8952
> 
> Title:  Captive Portal Architecture 
> Author: K. Larose,
> D. Dolson,
> H. Liu
> Status: Informational
> Stream: IETF
> Date:   November 2020
> Mailbox:k...@agilicus.com, 
> ddol...@acm.org, 
> liucou...@google.com
> Pages:  19
> Updates/Obsoletes/SeeAlso:   None
> 
> I-D Tag:draft-ietf-capport-architecture-10.txt
> 
> URL:https://www.rfc-editor.org/info/rfc8952
> 
> DOI:10.17487/RFC8952
> 
> This document describes a captive portal architecture. Network
> provisioning protocols such as DHCP or Router Advertisements (RAs),
> an optional signaling protocol, and an HTTP API are used to provide
> the solution.
> 
> This document is a product of the Captive Portal Interaction Working 
> Group of the IETF.
> 
> 
> INFORMATIONAL: This memo provides information for the Internet community.
> It does not specify an Internet standard of any kind. Distribution of
> this memo is unlimited.
> 
> This announcement is sent to the IETF-Announce and rfc-dist lists.
> To subscribe or unsubscribe, see
>   https://www.ietf.org/mailman/listinfo/ietf-announce
>   https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
> 
> For searching the RFC series, see https://www.rfc-editor.org/search
> For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk
> 
> Requests for special distribution should be addressed to either the
> author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution.
> 
> 
> The RFC Editor Team
> Association Management Solutions, LLC
> 
> 
> ___
> 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] [EXTERNAL] Re: [homenet] [Int-area] Evaluate impact of MAC address randomization to IP applications

[Martin Thomson]

There's an additional consideration that might be worth pulling out here.  And 
it's not an impact on network operations, it's a potential for applications 
that interact with these network services to undo the work of lower parts of 
their stack.

For instance, if your device connects to the same network and the same captive 
portal it might open a web browser to connect to that portal.  If the web 
browser presents the cookies it received from the portal last time they talked, 
it undoes the work of the OS.

Now, some implementations use these nasty browser-like things with aggressive 
sandboxing that don't save cookies.  That comes with other costs, but it 
addresses the problem up until the point that the network connection is 
restored and then who knows what happens once the pseudo-browser is no longer 
involved.

Maybe that is out of scope for your draft, but it shouldn't be out of scope for 
a group that attempts to look more closely at providing advice for dealing with 
these features.

(Does this thread really need to be cross-posted so widely?  Can we decide on a 
single venue?)

On Wed, Sep 23, 2020, at 07:24, Lee, Yiu wrote:
> Noted and clear. Will keep this in mind in the next update.
> 
> Thanks,
> Yiu
> 
> On 9/22/20, 5:18 PM, "Stephen Farrell"  wrote:
> 
> 
> Hiya,
> 
> On 22/09/2020 22:08, Lee, Yiu wrote:
> > Hi Stephen,
> >
> > Thanks for the notes. Actually, we believe that there are good
> > privacy reasons to randomize mac-address. This BoF isn't trying to
> > "fix" randomized mac-address. On the contrary, we want the community
> > to embrace it. In order to ease the anxiety for transitioning, we
> > want to document what may break and propose best practice to
> > transition to dynamic mac-address.
> 
> Sure, I get that. However, we've seen a number of these
> efforts start thusly but end up being perceived to be
> partly trying to unwind the privacy benefits, so I think
> a good way to avoid that mis-perception is to also present
> the reasons for (in this case, MAC address randomisation)
> as fully as the description of the challenges caused.
> 
> Cheers,
> S.
> 
> 
> >
> > Thanks, Yiu
> >
> >
> > On 9/22/20, 4:51 PM, "Int-area on behalf of Stephen Farrell"
> > 
> > wrote:
> >
> >
> > That agenda and draft seem to make the seemingly common enough
> > mistake of only focusing on what a new privacy or security 
> mechanism
> > breaks and glossing over the good reasons why people introduce 
> these
> > mechanisms. I hope the BoF proponents fix that because otherwise 
> they
> > may end up giving the impression that they would prefer to not see
> > the privacy benefits (which I'd guess is not their goal at all). 
> One
> > reason those good reasons need to be included is that they 
> constrain
> > the kinds of additions that might make sense to better handle the 
> new
> > mechanism.
> >
> > We've seen a number of these kinds of reactions and I figure it'd
> > really be better if the reaction were not to appear purely
> > reactionary;-)
> >
> > If that were fixed, then there may be a better discussion of 
> what, if
> > any, additional things need doing. If that is not fixed, I'd not 
> be
> > surprised if the putative BoF were to devolve into a "it's bad" 
> vs.
> > "no, it's good" bun fight that won't really take us further.
> >
> > Cheers, S.
> >
> > On 22/09/2020 21:40, Michael Richardson wrote:
> >>
> >> Damn. Spelt captive-portal without the s again.  Reposting, sorry
> >> for duplicates. I hate when WG names and list names do not match,
> >> and that we can't have aliases. And I think that reply-to gets
> >> filtered.
> >>
> >> Archived-At:
> >> 
>  >> > To: int-a...@ietf.org, captive-por...@ietf.org, 
> home...@ietf.org
> >> From: Michael Richardson  Date: Tue, 22 
> Sep
> >> 2020 16:34:33 -0400
> >>
> >> This thread was started today on the INTAREA WG ML.
> >>
> >> While I don't object to a BOF, I don't know where it goes. What I
> >> see is that much of this problem needs to be resolved through
> >> increased use of 802.1X: making WPA-Enterprise easier to use and
> >> setup, this changing core identity from MAC Address to IDevID.
> >>
> >> My understanding is that Apple intends to randomize MAC every 12
> >> hours, even on the same "LAN" (ESSID), and that they will just
> >> repeat the WPA authentication afterwards to get back on the
> >> network.   If the per-device unique policy (including CAPPORT
> >> authorization) can be tied to the device better, than the MAC
> >> address based "physical" 

Re: [Captive-portals] A final check on draft-ietf-capport-architecture-09

[Martin Thomson]

These cases, along with the very common case of a router that is on-premises 
and sits between an ISP and a local network, were discussed, but I don't recall 
ever reaching a conclusion.

On Tue, Sep 1, 2020, at 15:28, Erik Kline wrote:
> One thing I realized that we didn't discuss in 7710bis, and didn't 
> really discuss here either, is the issue of devices attached to routers 
> which are themselves on the link with the provisioning service.
> 
> Such clients would not have a way to receive an RA option nor any of 
> the DHCP options since we didn't say what routers that observe these on 
> a network should do (e.g. routers should/may include verbatim the 
> 7710bis options in any of the applicable mechanisms for downstream 
> clients).
> 
> The section 2.5 captive portal signal might be able to come to the 
> rescue here, but as we don't have such a thing.
> 
> But...maybe that's a separate document? 
> 
> On Sun, Aug 9, 2020 at 5:11 PM Martin Thomson  wrote:
> > The editors of draft-ietf-capport-architecture have put in a huge amount of 
> > work over the past few weeks in addressing the review comments.
> > 
> > https://tools.ietf.org/html/draft-ietf-capport-architecture-09
> > 
> > As there have been quite a few changes, I would like to request that people 
> > take a brief look again before we proceed.  I've been watching closely, and 
> > the changes look good, but I would like to confirm.  The changes are:
> > 
> > https://tools.ietf.org/rfcdiff?url2=draft-ietf-capport-architecture-09.txt
> > 
> > Please send comments before 2020-08-16.
> > 
> > ___
> > 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] A final check on draft-ietf-capport-architecture-09

[Martin Thomson]

On Mon, Aug 10, 2020, at 14:18, Michael Richardson wrote:
> I've read through the diffs:

Thanks!

> This was added based upon some review comment.
> While I can't really object to the idea, I am concerned.
> What are the transports that result in only being able to provide a public IP
> address? How many common PKI trust anchors are supporting iPAddress SANs 
> today?

There are no methods for providing an API URL that don't support a domain name. 
 That said, this iPAddress thing is just reiterating a requirement from RFC 
6125.  It isn't *widely* supported, but most clients do respect iPAddress SANs 
(browsers do for certain), and there are a couple of CAs that support issuance. 
 ACME recently grew a validation mechanism for IP (RFC 8738).

> I'd rather we didn't allow for iPAddress SANs, but it's not a sword I'll die 
> on.

Ack.  Personally, I'm more concerned about implementations allowing an override 
option other than through modifying the trust store.  A domain name is equally 
problematic there (let's hope we don't see .home addresses...).  But I don't 
see any easy path to a per-host override based on what I've seen in 
implementations so far.

> The next part says:
>   An Enforcement Device SHOULD allow access to any
>   services that User Equipment could need to contact to perform
>   certificate validation, such as OCSP responders, CRLs, and NTP
>   servers;
> 
> That's a good list, and that list can be seen from looking at the
> certificates that the captive portal operator is going to use.
> But, aren't there *also* systems (Mozilla? Chrome?) where the respective
> vendors are collecting that info into a central place to make stuff go
> faster?   I can't quite find what I'm looking for in a search, because
> OCSP-Stapling is not what I'm talking about, and eliminates the need.

Yes, browsers are providing systems that help with revocation.  Mozilla has 
OneCRL and CRLite; Chrome has CRLSets; offhand, I don't know what Microsoft and 
Apple might be doing differently.  Those systems that I'm aware of don't 
require network access at validation time.  The whole point being to provide 
timely information about revocation without depending on a live OCSP or CRL 
fetch (which have poor privacy properties in addition to adding to fragility).

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

Re: [Captive-portals] CAPPORT support in iOS 14 and macOS Big Sur betas

[Martin Thomson]

Tommy, this is great!  Thanks for all your work here, it's good to see this 
turn into something concrete.

On Tue, Jun 23, 2020, at 07:30, Tommy Pauly wrote:
> Hello CAPPORT,
> 
> I wanted to highlight an announcement we’ve made for the betas of iOS 
> and macOS released today:
> 
> How to modernize your captive network 
> 
> 
> The betas for iOS and macOS support both draft-ietf-capport-rfc7710bis 
> and draft-ietf-capport-api by default. This doesn’t change the user 
> experience of logging onto captive networks, but the system will 
> request the DHCP options and handle the RA option, and will prefer 
> using the Captive Portal API Server interaction over having a probe 
> that is intercepted.
> 
> If you have a portal system that is already implementing the CAPPORT 
> features, please test out these betas and let us know if you see any 
> issues! And if you have a captive portal solution, we’d encourage you 
> to start supporting this soon.
> 
> Best,
> Tommy
> ___
> 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] 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

[Martin Thomson]

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

[Martin Thomson]

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] Last Call: (CAPPORT Architecture) to Informational RFC

[Martin Thomson]

On Tue, May 12, 2020, at 22:32, Bob Harold wrote:
> >  How does the capport wg feel as a whole about this question? [MAC as 
> > identifier]
> 
> I am also wondering the same thing. 

We did discuss this, if I recall.  From memory, there were a few reasons not to 
go further:

MAC randomization means that the identifier might not be stable (I don't think 
that this is relevant in retrospect as MAC is no worse in this way than IP)

The nature of MAC and what entities could access that information means that it 
is more vulnerable to spoofing.  That is, an entity that is not on the same 
network segment would be unable to see the MAC and verify that incoming data 
was attributed to the UE.

No one volunteered to do a more thorough analysis.  As we have the generic 
criteria Kyle refers to, that was considered enough.

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

Re: [Captive-portals] Last Call: (CAPPORT Architecture) to Informational RFC

[Martin Thomson]

Editors,

I've opened a few issues on the comments Subash indicated were still pending.  
I think that we can take these as last call comments in the usual fashion.  I 
don't see a pressing reason to update the draft, but it would be nice if you 
could take a look at the remaining items to see if there is any action required.

On Tue, May 12, 2020, at 03:50, Tirupachur Comerica, Subash wrote:
>  
> Hi,
> 
> Sorry, I had sent these comments sometime back, a few are still valid.
> 
> Could you please take care of these?
> 
> 
> Thanks,
> 
> Subash
> 
> 
> 
> *From: *"Tirupachur Comerica, Subash" 
> 
> *Date: *Thursday, April 30, 2020 at 4:19 PM
> *To: *"captive-portals@ietf.org" 
> *Subject: *AD review of draft-ietf-capport-architecture-07
> 
> 
> Hi,
> 
> I was reviewing this AD and found a few discrepancy needing 
> clarifications, couple of them may just be editorial in nature.
> 
> Appreciate your response on this, thanks.
> 
> 
> Thanks,
> 
> Subash
> 
> 
> *_Section 1.2_*
> 
> Captive Network and Captive Portal are used interchangeably, so do we 
> define captive portal or network or both? – [Pending]
> 
> 
> *_Section 2.3_*
> 
> At minimum, the API MUST provide: (1) the state of captivity and (2) a 
> URI for the Captive Portal Server. – [Pending]
> 
> - However, in draft-ietf-capport-api, section 5: API State Structure, 
> only "captive" (boolean): is mandatory whereas "user-portal-url" 
> (string): is optional. One of these two drafts may need an update for 
> consistency.
> 
> *_ _*
> 
> *_Section 2.6 Component Diagram_*
> 
> Although the Provisioning Service, API Server, and Web Portal Server 
> functions are shown as discrete blocks, they could of course be 
> combined into a single element. – [Pending]
> 
> - Here may be we can add the [Captive Portal Enforcement] as well, for 
> eg: API Server, Web Portal Server and Enforcement can co-exist on a 
> single WiFi Access-Point using ACLs. Also there is a feeble reference 
> to this co-location in Section 3.4.1
> 
> 
> *_Section 3 Captive Portal Signal_*
> 
> Is Enforcement Device defined anywhere else? Is it same as Captive 
> Portal Enforcement(I guess so) Or does it coordinate with it? – 
> [Resolved, Please ignore]
> 
> 
> 
> *From: *Captive-portals  on behalf of 
> Bob Harold 
> *Date: *Monday, May 11, 2020 at 10:35 AM
> *To: *"last-c...@ietf.org" 
> *Cc: *"capport-cha...@ietf.org" , 
> "draft-ietf-capport-architect...@ietf.org" 
> , "captive-portals@ietf.org" 
> , IETF-Announce , 
> "barryle...@gmail.com" , Martin Thomson 
> 
> *Subject: *Re: [Captive-portals] Last Call: 
>  (CAPPORT Architecture) to 
> Informational RFC
> 
> 
> 
> I am curious why section 3.4 does not consider the MAC Address as a 
> possible identifier?
> 
> 
> -- 
> 
> Bob Harold
> 
> 
> 
> On Mon, May 11, 2020 at 12:56 PM The IESG  wrote:
> 
> > 
> >  The IESG has received a request from the Captive Portal Interaction WG
> >  (capport) to consider the following document: - 'CAPPORT Architecture'
> >   as Informational RFC
> > 
> >  The IESG plans to make a decision in the next few weeks, and solicits final
> >  comments on this action. Please send substantive comments to the
> > last-c...@ietf.org mailing lists by 2020-05-25. Exceptionally, comments may
> >  be sent to i...@ietf.org instead. In either case, please retain the 
> > beginning
> >  of the Subject line to allow automated sorting.
> > 
> >  Abstract
> > 
> > 
> >  This document describes a CAPPORT architecture. DHCP or Router
> >  Advertisements, an optional signaling protocol, and an HTTP API are
> >  used to provide the solution. The role of Provisioning Domains
> >  (PvDs) is described.
> > 
> > 
> > 
> > 
> >  The file can be obtained via
> > https://datatracker.ietf.org/doc/draft-ietf-capport-architecture/ 
> > <https://secure-web.cisco.com/1yVzqJ3UqY3xwLQUGHinMzu-7twa12PiLIN7EN50B62FLD0cXno02n3f_Qw7DSpKpG96CA7TKBLzu9xzC6TVQejhSfGo-jrF8DNmSa3LVszDOuk89O1tF28heTpZxo-Zl4Kzk3DxQoD5Hc8fDnwaLz69x04aBTgzTGR2Tf9ZMouiJgl4PjT97QOV7tu7viXpNVyNfM-2molaELtIJWJd00DqIJTzR2Hap7yETyceSjQTihOQh7tPi056W8nOWCQ-MxwbxsGzR5V37Soo1SFiKSaR_KHKYhK_NLd4ys-MQ_bKZmZiS_YEiEQX_q0lLjmFgTrqjGvQxzlOj0gwI4zthZQ/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-capport-architecture%2F>
> > 
> > 
> > 
> >  No IPR declarations have been submitted directly on this I-D.
> > 
> > 
> > 
> > 
> > 
> >  __

Re: [Captive-portals] Secdir last call review of draft-ietf-capport-rfc7710bis-04

[Martin Thomson]

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

Re: [Captive-portals] Captive-Portal Identification in DHCP / RA draft-ietf-capport-rfc7710bis-03

[Martin Thomson]

Thanks for the input.  Apparently great minds think alike as another reviewer 
found the exact same shortcoming just days ago.  The next revision should have 
these fixed.

On Tue, Apr 28, 2020, at 05:07, Tirupachur Comerica, Subash wrote:
>  
> Hi,
> 
> I was reviewing this draft and found a few missing text(sometimes 
> obvious) enumerated below(missing text in *_bold underline_*)
> 
> Section 2.1 IPv4 DHCP Option
> 
>  o Code: The Captive-Portal DHCPv4 option (TBD) (one octet).
> 
>  o Len: The length, in octets of the URI.*_(one octet)_*
> 
> Section 2.2: IPv6 DHCP Option
> 
>  o option-code: The Captive-Portal DHCPv6 option (103) (two octets).
> 
>  o option-len: The length, in octets of the URI.*_(two octets) --? 
> Please see question below_*
> 
>  o URI: The contact URI for the captive portal that the user should
> 
>  connect to (encoded following the rules in [RFC3986 
> ]).
> 
> 
> - *Question on the above option-len: If this is two octets in IPv6 DHCP 
> option, then the URI can be longer then 255. Option-len-value <=255, 
> correct?*
> 
> 
> Section 2.3: The Captive-Portal IPv6 RA Option
> 
>  o Type: 37*_(one octet)_*
> 
>  o Length: 8-bit unsigned integer. The length of the option
> 
>  (including the Type and Length fields) in units of 8 bytes.(*_one octet_*)
> 
>  o URI: The contact URI for the captive portal that the user should
> 
>  connect to. For the reasons described above, the implementer
> 
>  might want to use an IP address literal instead of a DNS name.
> 
>  This should be padded with NULL (0x0) to make the total option
> 
>  length (including the Type and Length fields) a multiple of 8
> 
>  bytes.
> 
> 
> Thanks,
> 
> Subash
> 
> 
> ___
> 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] Publication has been requested for draft-ietf-capport-api-06

[Martin Thomson via Datatracker]

Martin Thomson has requested publication of draft-ietf-capport-api-06 as 
Proposed Standard on behalf of the CAPPORT working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-capport-api/


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

[Captive-portals] Publication has been requested for draft-ietf-capport-architecture-07

[Martin Thomson via Datatracker]

Martin Thomson has requested publication of draft-ietf-capport-architecture-07 
as Informational on behalf of the CAPPORT working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-capport-architecture/


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

[Captive-portals] Publication has been requested for draft-ietf-capport-rfc7710bis-03

[Martin Thomson via Datatracker]

Martin Thomson has requested publication of draft-ietf-capport-rfc7710bis-03 as 
Proposed Standard on behalf of the CAPPORT working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-capport-rfc7710bis/


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

[Captive-portals] WGLC ends for all drafts

[Martin Thomson]

Thanks to everyone who reviewed and contributed to these drafts.  That includes 
7710bis, the architecture and API documents.

There were a few issues raised during WGLC, but as far as I can see, nothing 
that would prevent us from proceeding.  I've asked the editors to try to 
resolve those and provide updated drafts and we'll move on to publication when 
that happens.

We aren't done yet, as these changes might cause more discussion and there are 
directorate and IESG reviews yet to come, but this is a significant milestone.

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

Re: [Captive-portals] WGLC on draft-ietf-capport-architecture and ...-api

[Martin Thomson]

Thanks for doing this Gurshabad.

I think we've debated the removal of the signaling section on a number of 
occasions.  Could this text perhaps be reduced to something simpler, especially 
in light of our decision not to specify anything?

Perhaps:

--->8--
When User Equipment first connects to a network, or when there are changes in 
status, the Enforcement Device could generate a signal toward the User 
Equipment.  This signal indicates that the User Equipment might need to contact 
the API Server to receive updated information.  For instance, this signal might 
be generated when the end of a session is imminent.

An Enforcement Device MUST rate limit any signal; User Equipment MUST rate 
limit attempts to contact the API Server; see Section 7.4.
--8<---

That loses a lot of text, but I don't know that any of what is presently there 
is critical.  For instance, the current text recommends against a spoofable 
signal, but doesn't really say what it means to spoof.

What do the editors of the spec think?

On Tue, Mar 24, 2020, at 13:52, Gurshabad Grover wrote:
> On 3/5/20 12:25 PM, Martin Thomson wrote:> This starts a joint working
> group last call on these documents. Please respond this mail with your
> views regarding the suitability of these documents for publication (as
> Informational RFC and Proposed Standard RFC respectively) before 2020-03-23.
> > 
> 
> Thanks for all the great work, authors and editors! I have reviewed
> capport-architecture, and I support its publication as an RFC. Some
> comments below.
> 
> On capport signal
> -
> The Captive Portal Signal section (2.5) was a bit confusing to me.
> 
> Is 'signal' only meant to be binary information, i.e. whether traffic is
> restricted or not? (pt. 3 in the section) If yes, the inclusion of a
> 'pending expiry' notification in the same section seems contradictory.
> (It also assumes that some information is available since "On receipt of
> preemptive notification, the User Equipment can prompt the user to
> refresh.")
> 
> I think the clearest explanation of it is offered in the Security
> Considerations rather than the section itself, i.e. the signal should
> not carry any information at all, that it just acts as a prompt for the
> User Equipment to contact the API. (This explanation makes other things
> fall in line as well: the 'pending expiry' notification is just a
> timed-signal that is no different from any other except for when it was
> triggered.)
> 
> I would suggest rephrasing sentences in the Captive Portals section to
> make them as clear as the security considerations text. If my
> understanding is correct, please let me know and I'm happy to submit a
> PR to this effect.
> 
> 
> Pull request
> 
> I have submitted a pull request with some editorial suggestions; happy
> to elaborate on them if the motivation is not clear from the changes.
> <https://github.com/capport-wg/architecture/pull/51>
> 
> 
> Privacy considerations
> --
> Since we're dealing with unique identifiers and traffic information,
> would love to hear people's thoughts on whether a brief privacy
> considerations section would be useful. If yes, happy to help with that.
> 
> 
> 
> Thank you.
> -Gurshabad
>

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

[Captive-portals] IETF 107 capport session cancelled

[Martin Thomson]

After consultation with my co-chair and our area director, we have agreed to 
cancel the capport meeting at IETF 107.

As all of our documents are currently in WGLC, I think that it would be best 
for people to devote their time and attention to reviews of those documents.  
As a reminder, you have around 2 weeks to complete any reviews.  Thanks to 
those people who have contributed reviews (and text!) already.

Regards,
Martin (for the chairs)

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

[Captive-portals] WGLC on draft-ietf-capport-architecture and ...-api

[Martin Thomson]

Hi folks, 

Our fine editor teams have contributed updates to these drafts.

https://tools.ietf.org/html/draft-ietf-capport-architecture-06
https://tools.ietf.org/html/draft-ietf-capport-api-05

This starts a joint working group last call on these documents. Please respond 
this mail with your views regarding the suitability of these documents for 
publication (as Informational RFC and Proposed Standard RFC respectively) 
before 2020-03-23.

There are a few minor issues, but I consider those to be minor enough to 
require only trivial fixes. Some appear to be already addressed. If you think 
that major changes are needed, or have proposed resolutions to issues, adding 
those to your email would be helpful.

Issues are tracked here:
https://github.com/capport-wg/architecture/issues
https://github.com/capport-wg/api/issues

I encourage people to add issues to the tracker as they review these documents. 
Directly raising minor editorial issues on GitHub will help us focus attention 
on substantive issues here.

Cheers,
Martin (and Erik)

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

Re: [Captive-portals] WGLC on draft-ietf-capport-rfc7710bis-01

[Martin Thomson]

I have two minor comments of my own to add:

The prioritization section (S3) suggests that conflicting sources of URIs be 
prioritized.  However, this specifically avoids stating any preferred order.  
Rather than saying we don't specify it, how about explicitly letting 
implementations decide?

OLD:
   URI precedence in this situation is not
   specified by this document.
OLD:
   Implementations can select their own precedence order.

The security considerations (S5) includes this text:

   Operating systems should conduct all interactions with the API in a
   sand-boxed environment and with a configuration that minimizes
   tracking risks.

I would suggest that this is a bad idea.  I personally would recommend against 
it.  It might have been wise in the past when HTTPS rates were lower, but 2020 
is not 2014.  Captive portals occasionally do things like access SSO services 
(Facebook being one) and a sandbox often doesn't have access to the same 
persistent storage as a genuine browser.  Asking people to enter passwords in a 
sandbox can have the effect of building insensitivity to phishing attempts; 
especially when that sandbox could have limited anti-phishing capabilities 
compared to a full-fat browser.

I realize that this is in tension with the desire to minimize tracking of 
people across points of physical connectivity.  I think that the best we can do 
is recognize that tension and let people reach their own conclusions.

On Mon, Mar 2, 2020, at 09:49, Martin Thomson wrote:
> Hi everyone,
> 
> The editors of draft-ietf-capport-rfc7710bis-01 believe it to be ready 
> for publication.
> 
> Please send comments on this before 2020-03-16.
> 
> Comments supporting publication as-is are valued as much as comments 
> highlighting issues.
> 
> Note that Erik is an editor of this document, so he won't be assessing 
> consensus.
> 
> ___
> 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] WGLC on draft-ietf-capport-rfc7710bis-01

[Martin Thomson]

Hi everyone,

The editors of draft-ietf-capport-rfc7710bis-01 believe it to be ready for 
publication.

Please send comments on this before 2020-03-16.

Comments supporting publication as-is are valued as much as comments 
highlighting issues.

Note that Erik is an editor of this document, so he won't be assessing 
consensus.

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

Re: [Captive-portals] Remediation url for CAPPORT

[Martin Thomson]

On Mon, Jan 20, 2020, at 17:54, Michael Richardson wrote:
> There are a number of locations where you get 20 minutes free, and then you
> have to purchase the extension. That doesn't seem to fit into remedial to
> me. (Montreal Airport comes to mind)
> 
> I guess such locations have an incentive to put something other than "you're
> logged in" on that page. What should such a location do? Do they say the
> offer extensions, or not?

I don't see why not.  Now you might not be inclined to sell your first-born 
child [1] to continue, but it's not like the option isn't there.

[1] ...or kidney, or whatever more reasonable terms the network might offer.

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

[Captive-portals] Notes from todays informal meeting

[Martin Thomson]

Mention PvD in the architecture as it is in AD review

7710bis link relation shall be removed
codepoint 160? we should deprecate 160, register it for polycom, pick a new 
one, and document the experience.  This requires IETF review.

gStation overview
 - everything works fine
 - v4 only
 - dynamic JSON includes MAC of device
 - happily uses HTTPS, the device already needs a certificate for other reasons
 - the API can't be accessed from outside the network
 - the venue info URL is cloud-hosted

Discussion about accessing resources.
portal URL might be better if it were accessible from outside the network.  
Maybe recommend that URLs other than the API doc be public and be accessible 
from other networks.  Maybe recommend that they not require that applications 
use the DNS.  They should be unique for the venue, not with content that varies 
based on where the request comes from.  Issue filed on architecture doc.

Changes to API discussed and agreed, recorded in issues in the repository.

Experiment for Vancouver IETF.  Desire to get the RA working.  Desire to get a 
real portal on the network (on a different SSID maybe).

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

Re: [Captive-portals] Discovering captive portal API URL via DNS?

[Martin Thomson]

What about those resolvers that collapse CNAME responses, effectively eliding 
them?

I assume that you are going to explicitly say that this has to be directed to 
the resolver provided in network configuration.  If that resolver is outside 
the network or less tightly secured than DHCP/RAs, then we have the possibility 
of attack on the DNS-over-UDP-53 that is used to get the CNAME response.

(Just contributin' not chairin'.)

On Wed, Sep 4, 2019, at 09:44, Lorenzo Colitti wrote:
> All,
> 
> During discussions with captive portal operators about implementing the 
> capport API, one of the stumbling blocks that keeps coming up is that 
> the captive portal operator does not always control the DHCP 
> configuration and thus cannot easily use RFC7710.
> 
> The WG has previously rejected the option of using a well-known DNS 
> name to discover the URL, because the API itself requires TLS, and 
> without a hostname it is not possible (or at least not easy) to 
> validate the server. However, what if the client did a CNAME query for 
> capport.arpa (or equivalent other local-only, non-DNSSEC-signed name), 
> got back a CNAME for the real server, and then assumed that the API 
> server was https:///capport-api ?
> 
> Alternatively, Erik and Warren suggest RFC 7553. In this scheme the 
> client would do a URI lookup for "capport.arpa" or equivalent, and 
> would take the result of that URL as the API endpoint.
> 
> Thoughts?
> 
> Regards,
> Lorenzo
> ___
> 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] Review of draft-ietf-capport-rfc7710bis

[Martin Thomson]

If DHCP is used, then it is possible to customize the API URL to include 
per-device information.  In that case, the API could be remote.

However, an IPv6 RA has to contain information that is the same for every 
device in the network.

On Wed, Jul 31, 2019, at 13:44, Chris Spencer wrote:
> Please forgive, I'm new to this group and trying to come up to speed.
> 
> Would not a feed of option 82 rather than create a new API work? option 
> 82 can carry MAC/IP (it could create a GUID/UUID) and other location 
> identifiers? if the external portal could get a feed of this, the 
> portal at layer 3 could look up the device MAC from the option 82 
> elements by the IP? or if the DHCP server is centralised along with the 
> portal architecture and DHCP relay is used on the local site?
> 
> -
> DHCP Option 82 Overview
> If DHCP option 82 is enabled on a VLAN or bridge domain, then when a 
> network device—a DHCP client—that is connected to the VLAN or bridge 
> domain on an untrusted interface sends a DHCP request, the switching 
> device inserts information about the client's network location into the 
> packet header of that request."
> 
> 
> On Wed, 31 Jul 2019 at 04:24, Martin Thomson  wrote:
> > This is one of the costs of this architecture. If the external system 
> > (portal HTML, etc...) needs access to identifiers, then the API endpoint 
> > will have to decorate the URLs it provides. That might mean having the API 
> > endpoint inside the network, where it can see source IP or BSSID or 
> > whatever is being used for identification. 
> > 
> >  An external service won't be able to validate any identifier it receives 
> > in this way, so you might want to make the decoration a little more complex 
> > than a simple addition of `?ip=192.0.2.3`. Of course, the worst I can think 
> > of (offhand) is that someone could pay for my network access.
> > 
> >  On Mon, Jul 29, 2019, at 13:51, Remi NGUYEN VAN wrote:
> >  > So to summarize, we've got a problem where the WLAN controller has some 
> >  > rules to know who is blocked / allowed (probably based on mac address 
> >  > ?), and can advertise a single API URL through DHCP / RAs / 
> >  > Link-Relation and generate redirects, but does not have capabilities to 
> >  > serve login pages or the API: this is handled by another box upstream 
> >  > which has more capabilities like handling payment pages etc, and holds 
> >  > the SSL certs. Because the API uses HTTPS (contrary to lots of login 
> >  > pages), the WLAN controller can't easily insert identity of the 
> >  > requestor in the request and the API has no way to know who it's 
> >  > replying to.
> >  > 
> >  > Since we can't advertise different addresses for different clients in 
> >  > RAs, how about having the client add a session identifier in their API 
> >  > requests ? Having the client add a mac address in an HTTP request 
> >  > header field would be a solution. Many devices are using random 
> >  > per-SSID mac addresses now, so this sounds like a reasonable identifier 
> >  > for the device to give to the API server (which could get it anyway 
> >  > through some complicated setup).. It would be possible for clients to 
> >  > make requests for API data of other clients (assuming they know their 
> >  > mac address), but that's already possible by spoofing the address 
> >  > anyway.
> >  > 
> >  > Cheers,
> >  > 
> >  > Remi
> >  > 
> >  > 
> >  > On Sat, Jul 27, 2019 at 8:04 AM Michael Richardson 
> >  > mailto:mcr%2bi...@sandelman.ca> 
> > <mailto:mcr%2bi...@sandelman.ca <mailto:mcr%252bi...@sandelman.ca>>> wrote:
> >  > > 
> >  > > Lorenzo Colitti  wrote:
> >  > > > Is there a problem with saying that the portal server should 
> > identify the
> >  > > > device by IP address?
> >  > > 
> >  > > Tommy Pauly  wrote:
> >  > > > To that end, any enforcement of other traffic (such as normal web 
> > page
> >  > > > loading) will not be carrying any session identifier, so only signals
> >  > > > that are already present in the packets, such as the IP address, are
> >  > > > effectively useful here.
> >  > > 
> >  > > It's not obvious to me that you are talking about the same thing!
> >  > > The portal server *could* use IP address as the key by which to 
> > identify
> >  > > the device to the Captive Portal Enforcer.
> >  > > 
> >  > > That requires that the a

Re: [Captive-portals] Call for adoption draft-ekwk-capport-rfc7710bis

[Martin Thomson]

On Fri, Jun 14, 2019, at 04:57, Warren Kumari wrote:
> Can you please let the list know what your consensus assessment is [...]?

My sincerest apologies for letting this drop.  My remainder got eaten by a pet. 
 I probably need a "does not operate any internal timers" warning printed 
somewhere.

Yes, there seems to be sufficient support for adoption.

Authors, please submit a -ietf- version at your convenience.  Erik should have 
the necessary privileges to move this over to the capport-wg organization there.

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

[Captive-portals] Call for adoption draft-ekwk-capport-rfc7710bis

[Martin Thomson]

Erik and Warren have helpfully provided this draft that updates RFC 7710.  
Today we discussed this and there seemed to be general agreement to adopt.  

Please respond to this email before 2019-04-12 stating whether you think we 
should adopt or not.  If not, please share your reasons when you say this.

I'll be assessing consensus on this document, because my co-chair is an author.

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

[Captive-portals] Agenda for next week

[Martin Thomson]

Hi Folks,

I've uploaded an agenda for next week.  See below.

As part of this, I plan to review the mailing list and pull out issues that 
have been raised so that we can discuss those issues in the meeting.  The goal 
will be to decide whether we're ready for WGLC on the drafts we have.

~~~

CAPPORT Working Group
IETF 104
Prague
2019-03-27
11:20-13:20 Second Wednesday session, Karlin 3
Chairs: Erik Kline, Martin Thomson
Materials: https://github.com/capport-wg/wg-materials/tree/master/ietf104

Agenda

Administrivia  5   Chairs
  - Agenda bash

Draft Status
  - Architecture (update)  5  Chairs
https://tools.ietf.org/html/draft-ietf-capport-architecture-03
  - API (update)   10  Tommy
https://tools.ietf.org/html/draft-ietf-capport-api-02

What does "done" look like for this group?  Chairs

AOB

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

[Captive-portals] Meeting at IETF 103

[Martin Thomson]

After not having any concrete agenda for a meeting, I cancelled our
meeting.  However, there was considerable interest in meeting from a
few people.

I've reserved the IAB room (Boromphimarn 5, on the third floor) at
11:20 on Thursday, the time we were originally scheduled.  We need to
be out by 12:20.

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

Re: [Captive-portals] Signals from the network and ICMP

[Martin Thomson]

Just to reiterate what Erik said here.  Based on the discussion in London
we have a better (but not perfect) understanding of what a signal would
need to look like.  But until we have a concrete proposal that fits the
requirements, all we have is a liability.  As a chair, I'm interested in us
completing our work and decoupling a contentious - and therefore risky -
component allows us to complete some work.

I encourage those who believe that a signal is important to make a
proposal.  My strong sense from the group is that
draft-wkumari-capport-icmp-unreach is a too ambitious, but something along
the lines of what is currently described in the architecture document -
which is much more narrowly constrained along the lines Dave (Dolson)
described upthread - might reach consensus.

I think that we were close to agreement about a simple signal that prompted
checking with the API.  I know that David (Bird) has some reservations
about this regarding the layer at which signals are produced and consumed,
but my sense is that the group felt that it was easier if any rich
signaling was kept at a higher layer of the stack.

The form of that signal is next to consider.  We have discussed ICMP
DestUnreach with a both new and existing codes.  The feedback in London was
that maybe DestUnreach has some downsides and a new message would be
better.  A new ICMP message would allow for use prior to the network access
being revoked, so it has that in its favour.  Then there are other methods
for signaling, such as a UDP packet to a registered port.

If someone were willing to present a solution that meets all the
requirements (or presented arguments for why particular requirements aren't
applicable or necessary), then I think we could proceed and we would talk
about adoption.  That would allow all our documents to proceed together.

Until we have that proposal, this signaling channel is a risk.  The
solution we have isn't an ideal solution from all perspectives without this
signal.  However, I think that we have a substantial number of people (if
not consensus) that - even with no signal - what we have is an
improvement.  More importantly, that we are not preventing the later
addition of a signal.

Therefore, until we have a concrete solution, I suggest the following
concrete actions:

1. remove the "hmac-key" from the API (that's easy, and I think that we're
resolved on that point)

2. make the text on the signal generic rather than specifically talking
about ICMP

3. some to volunteer to design a simplified signal and propose a design

On this second point, I'd suggest that the editors hold off on making that
change so that we can let this discussion evolve a little more.  It seems
like we are still undecided here and I wouldn't want to make the change,
discover that we have a draft that has consensus, and then revert it soon
afterwards.

On Tue, May 1, 2018 at 1:56 PM Erik Kline  wrote:

> I was unable to make it to London, but I was able to watch the session
> on Youtube.  The ICMP discussion begins here:

>  https://www.youtube.com/watch?v=tavhoXNVcP8=1h12m5s

> and carries on until Darshak's presentation starts at t=1h45m35s (a
> good 30+ minutes).

> My reading of that portion of the session was not that ICMP was
> "unsuitable", but rather that there wasn't consensus in the room to
> move forward with anything in particular at that time--other than a
> discussion about requirements (i.e. the thread to which Martin
> linked).

> I would say the aim here was to "unhook" the ICMP discussion from the
> other work (architecture-cum-API), so both could proceed at their
> relative paces.

> 

Re: [Captive-portals] Fixing RFC 7710

[Martin Thomson]

On Sat, Mar 3, 2018 at 8:58 AM, Ólafur Guðmundsson
 wrote:
> Fixing or make RFC7710 more useful ?

Both, I hope.

Thanks for your reply.

>> Erik and I would like to propose a plan for that work.  We would keep
>> this to addressing the issues that we have identified thus far.
>> Namely:
>>
>> 1. The purpose of the URI is not well defined.  We would reference the
>> capport architecture and API documents for that.  The group would need
>> to decide between:
>>   a. point to the API
>>   b. point to a login page
>>
>
> Our (or at least my thought) was in the beginning,
> just send the device to the location of the portal, as I hate having
> connections intercepted.
> Then the USER could just see that page and decide what to do.

I think that the idea is this:

If the URI is the special one, then the process is done and the
network good to use.
If the URI is special, find the API and check status.  If the portal
says OK, then the network is good to use.
If the API returns captive, open the login page in a browser.

We don't have any more automation than this, but you will observe that
there isn't any probing.  The network can make a clear statement
quickly an unambiguously about access.  If the situation is more
complex (as we have seen that it often is, then it can use the login
page to convey that additional information).

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

Re: [Captive-portals] I-D Action: draft-ietf-capport-api-00.txt

[Martin Thomson]

On Tue, Feb 6, 2018 at 12:07 PM, David Bird  wrote:
>> I'd say that the amount of information provided here is rich enough
>> that you want to talk to a human.  Very few networks permit sending of
>> arbitrary packets to arbitrary hosts and the receipt of similar.  The
>> point is to ensure that you are managing expectations.  If I
>> understand the expression of requirements, the idea is that a UE can
>> use the boolean signal, but this other stuff is better presented on
>> the web page.  If the network starts off in a captive state, then that
>> page will be seen (if there is a human), and maybe not used (if there
>> isn't).
>>
>
> I'm not sure I follow that statement...

I'll try again, because that was a little dense.

You asserted (or implied) that a Boolean value was insufficiently
expressive to convey the range of possible policies that a captive
network might impose.  I asserted that while that is true, whatever
you do will be turned into a go/no-go decision by the UE.  This value
is giving the network provider a direct input to that decision.

I acknowledge that you might conclude that we're back to gaming this
out, but I have heard UE vendors say that they really don't want to
probe.  So if the network says that it's good, I think that they will
save the probing for when the network breaks instead.  But we'll let
Tommy and Lorenzo respond.

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

Re: [Captive-portals] I-D Action: draft-ietf-capport-api-00.txt

[Martin Thomson]

On Tue, Feb 6, 2018 at 8:41 AM, David Bird  wrote:
>> I have heard UE vendors express a strong desire to be able to know
>> about status before they attempt to use the network.
>>
>
> Hm, but (assuming you are using the provided network for DNS, CRL checks,
> and the API itself), the UE is *already* using the network.

Not really.  The way I understand it, the UE alters routing tables so
that only applications that explicitly opt in to using the interface
to the network can do so.  That state exists until the network is
given an "all clear".

> I believe this desire on the UE vendor part is a case of 'be careful what
> you wish for' ... Having an API telling you it is "all clear" vs "do
> internal (often sandboxed for various reasons browser) captive portal
> dialog" amounts to making this a configuration of the network administrator
> -- Remember the (current) arms race concerning captive  portal detection?
> Well, the network operator wins with this API (!).

Remember we already concluded that if the network wants to lie about
status, we aren't planning to stop them.  There are still some
discussions to be had about providing incentives to be truthful, but
it's possible that we could never really plumb the depths of that
issue productively, so we've been deferring it.

> Over the years on this list we have seen many use-cases come through, I
> recall:
>
> -  A school/library network that allows most of the Internet, but captures
> and redirects for certain networks / sites
> -  A network allows all sorts of protocols - IMAP, HTTPS, for example -
> but not others - like HTTP, SMTP - and want to redirect / signal portal
> -  A network that allows all Internet traffic, but just at a low QoS tier.
> No "captive" portal, but a portal is  yet available for upgrading tier
> -  Any network that allows a large walled garden, or even a *very large*
> garden, but otherwise has a captive portal
> -  A network that will 99.99% of the time allow all traffic, but will
> (perhaps because of virus detection) interrupts sessions  into captive state
> [technically, this is a "boolean" use-case, but one where polling would just
> be huge noise]

I'd say that the amount of information provided here is rich enough
that you want to talk to a human.  Very few networks permit sending of
arbitrary packets to arbitrary hosts and the receipt of similar.  The
point is to ensure that you are managing expectations.  If I
understand the expression of requirements, the idea is that a UE can
use the boolean signal, but this other stuff is better presented on
the web page.  If the network starts off in a captive state, then that
page will be seen (if there is a human), and maybe not used (if there
isn't).

> Clients that go idle typically have their session terminated - so, yes, it
> does save the user time (depending on "time" is billed - real time vs
> metered, etc).

Right.  Though this is relatively rare in my experience.  In those
cases, I think that the idea is that the client can check with the API
before its time comes due and notice the resulting extension and so go
back to sleep.

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

Re: [Captive-portals] I-D Action: draft-ietf-capport-api-00.txt

[Martin Thomson]

On Tue, Feb 6, 2018 at 5:03 AM, David Bird  wrote:
> Thanks Darshak and Tommy, this is really helpful.

Yes, thank you both.

> Some comments:
>
> In 2. Workflow: Does it make sense to reorder 2) and 3)? It would seem
> 'Enforcement' should come before determining status (of said enforcement)
> and how to proceed. I would argue that the UE might as well try to use the
> network and wait for the network to respond (e.g. with Enforcement and/or
> routing notifications/errors. Indeed, the UE sorta already *did* this if it
> resolved DNS and checked certificate status of the API server hostname.

I have heard UE vendors express a strong desire to be able to know
about status before they attempt to use the network.

> In 3.1 URI of Captive Portal endpoint, I think we must go beyond making TLS
> a MUST --- we need to define how trust is handled. We must require the API
> client to validate the hostname, present that hostname to the user for
> acknowledgement. Or, are we explicitly saying that TLS is for privacy and
> not security? (e.g. that we really don't care what the server cert is...
> just that the cert is consistent for that location / domain?). Is the client
> expected to check revocation lists?

Good point.  This is likely an architecture question in the sense that
we need to determine what the trust model is and where that is
anchored.  We have an established pattern already where we trust that
the initial bootstrapping protocols (DHCP, RAs) produce a URL that is
accurate.  Once you have a URL, the rest of the process needs to
follow the rules: clients are expected to follow the usual rules for
server authentication.

In this particular case, we should explore that last point further,
because CRLs or OCSP are likely to fail in this sort of environment.
That's relatively easy to address, but we would have to mandate OCSP
stapling.

I've opened an issue: https://github.com/capport-wg/api/issues/7

> In 3.2, ' "permitted" (required, boolean): indicates whether or not the
> Captive Portal is open to the requesting host ' is confusing... does it mean
> the UE is subject to a captive portal?  I dislike how boolean this is! Why
> does it have to be all or nothing (especially if ICMP is providing
> enforcement notification?)

Can you motivate something less boolean?  That's a question we've
struggled with.

> Also in 3.2, I'm not sure about the time/data remaining info.. Is the
> expectation that the client keeps polling? (never goes idle on any network?)
> Is the expectation that the UE  will break connections after it sees this
> API expire timer or counter, or shall the (smart) UE wait until the network
> notification (ICMP) ?

I think that the way this is intended to work is that the UE will
contact the actual portal some time in advance of this time.

Why do you ask about polling?  Are there networks that will extend
active time in the case that clients go idle?

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

Re: [Captive-portals] API access and .well-known

[Martin Thomson]

On Fri, Jan 19, 2018 at 9:33 AM, Adam Roach  wrote:
> Sure, either in a 3xx response; or, if we're using Link: relations, those
> URLs can vary based on the client. If you want to get fancy about it, you
> can even have your DHCP server hand out different URLs in the RFC7710 field.
> There are a lot of ways to deal with multi-tenancy.

Adam is correct.  Note that DHCP offers the possibility of per-client
configuration, which is something not available with a RA.

Note also that if you believe it necessary to provide the client with
an identifier using any of these opportunities, you need to
authenticate it later, lest the client switch it out on you.  This
might not give the client the ability to piggy back on top of another
client's access, but it might lead to privacy violations.

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

Re: [Captive-portals] API access and .well-known

[Martin Thomson]

Right, I neglected to mention that option.  Call it (d) link relations.

You might also do the reverse in the API-first arrangement that Tommy
suggests (API at the URL, HTML at the other end of a link relation).
It seems likely that 7710 deployment is scant enough that we would be
free to make this decision without being constrained to deal with
backwards compatibility.

One likely deployment involves the thing that is configured being
different to the thing that ultimately serves the content (for reasons
of sorting out the UE identification, if nothing else), so it's
possible that Adam's suggestion here doesn't add round trips that
weren't already needed.

On Wed, Jan 17, 2018 at 9:44 AM, Adam Roach <a...@nostrum.com> wrote:
> [as an individual]
>
> I agree that we should strictly avoid synthesizing URLs in general, and
> should try to avoid .well-known URLs in particular. Sometimes you're forced
> to use .well-known (e.g., when there's literally no way to get a full URL to
> the client), but that doesn't seem to be the case here.
>
>
> On 1/14/18 11:39 PM, Martin Thomson wrote:
>
> a. use .well-known and just provide better justification for it
> b. use content negotiation
> c. find some way to get two URIs, like revising 7710 or finding an
> alternative mechanism (such as the one in RFC 5986)
>
>
> For what it's worth, I don't think (a) is possible -- I don't believe any
> plausible justification text can be put together that explains why other
> approaches are infeasible.
>
> Something else to consider is serving up the HTML portal on the endpoint you
> get from RFC7710, and including a link-relation [RFC5988] header field that
> points to the API; e.g.:
>
>
> HTTP/1.1 200 OK
> Link: <https://portal-api.example.com/json/>;rel="capport-api"
> Content-Type: text/html
>
>  ...
> [legacy portal page goes here]...
> 
>
>
> Importantly: clients interested only in the API can simply perform a HEAD
> rather than a GET to retrieve the Link information. I'll note that this
> provides a clear extension point if you decide you need yet a third thing to
> be discoverable and/or need different HTTP endpoints for versioning in the
> future. I do note that it requires an additional round trip, similar to the
> redirection approach that has been discussed in conjunction with content
> negotiation. Notably, taking this approach eliminates the need for
> redirects, since the link header can point to any arbitrary URL.
>
> /a

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

[Captive-portals] API access and .well-known

[Martin Thomson]

(see also https://github.com/capport-wg/api/issues/2)

Currently the API draft proposes use of .well-known for finding the
API.  Generally speaking, there's a trend toward avoiding use of
.well-known except when either:

* it is difficult to configure or provide a full URL, or
* the .well-known provides information about the origin as a whole.

In this case, the latter definitely doesn't apply, but I think we
should probably discuss the former a little.

The problem we have is that there are really two URLs we care about
and 7710 only provides one.  (PvD might provide two URLs, so we don't
need to worry about this problem for PvD.)

The old API draft used HTTP method to distinguish the two uses: GET
for HTML that you might show to a person; POST for an API.  But the
new, leaner API uses GET too, so that's not an option we can use.

HTTP content negotiation is another option here.  It's pretty
well-supported on the whole aside from a few wrinkles around caching.
I suspect we will find that caching will be infeasible for other
reasons (see the other issues on GitHub for a taste of that).  Content
negotiation works [1] by having the client send an Accept header field
with a new media type (straw man: application/capport+json) and the
server would detect this and send back an API response or redirect to
the API endpoint.  If this content-type wasn't present, it could send
back HTML (or a redirect to a server that does).

Here's the options I see:

a. use .well-known and just provide better justification for it
b. use content negotiation
c. find some way to get two URIs, like revising 7710 or finding an
alternative mechanism (such as the one in RFC 5986)

Tommy notes that this has a drawback in that it forces the web UI and
API to be co-located.  I don't think that is necessarily true if you
accept that HTTP-level redirects are possible.  Indeed, that is how
many enforcement points work today: they terminate a connection
locally but then redirect to more capable servers.  Also, using
.well-known doesn't really make the resources any less co-located
because the origin - and the server - are still the same.

What do folks prefer here?

[1] Content negotiation can use other properties of the request as
well, but Accept is common and pretty widely supported.

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

[Captive-portals] UE Identification

[Martin Thomson]

Thanks Kyle for the summary of the discussion.

The chairs would like to focus your attention on the issue of User
Equipment identification.  The basic problem is that the enforcement
point and API are two different entities.  They might also need to
talk about the UE with other entities (RADIUS servers, logging
systems, payment systems, and all sorts of backend systems).

How should the UE be identified?

We had a great discussion about this in Singapore and it's the view of
the chairs that there was no consensus for defining a set of UE
identifiers for explicit use in the protocols.  There were a few
reasons for this. One was that it would be difficult to find a set of
identifiers that would work for all deployments.  Also, allowing the
UE to include identifiers would increase the risk that the UE spoofs
those identifiers.

The two options that were discussed at length both involved having the
UE identified implicitly.  That is, some property of the packets that
arrive at the enforcement point would be used to identify the UE.  The
concern being that the identifier(s) were not subject to spoofing.
MAC, IP, or the circuit on which the packets arrive might all be
acceptable.

There was some discussion about how to manage consistent
identification between API and enforcement.  From the discussion, we
appear to have two options:

1. Identify the UE at the API the same way that it is identified at
enforcement.  API and enforcement would have to agree on the
identifier they use.  This would also constrain deployments so that
the API has to be located on the network in a position where
spoofing identifiers isn't possible.

2. Have the enforcement device pass an identifier (a "session ID") to
the UE for use with the API.  The enforcement would probably use an
ICMP extension to pass this information back.  This would need to be
authenticated, so that the UE couldn't generate a valid identifier.
There was plenty of discussion about that, but the short summary is
that this is possible if we want to have it happen.

It seems like there is some sense that the first option was preferred.
We'd like to get a sense of the list here.  Which of these options is
preferable, and why?

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

[Captive-portals] Capport at the hackathon

[Martin Thomson]

FYI,

I've tentatively registered interest in capport work at the hackathon.
For those interested in participating, I hope that you can join us.

See https://www.ietf.org/registration/MeetingWiki/wiki/doku.php?id=100hackathon

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

Re: [Captive-portals] [adoption call] draft-larose-capport-architecture

[Martin Thomson]

I've created a repository for the architecture draft at
https://github.com/capport-wg/architecture

I'll send a separate email with the process I think we should use for GitHub.

Kyle and David, you have been invited to the repository.  If you need
help setting the repository up, let me know (I found your repository
at https://github.com/dcdolson/draft-capport-architecture and can do
the setup if you like, once you confirm that this is up to date).


On Thu, Sep 28, 2017 at 3:22 PM, Erik Kline  wrote:
> (long overdue update)
>
> There having been no dissent, objections, or concerns raised consensus
> is that the group would like to adopt this document.
>
> Please re-upload draft-larose-capport-architecture-01 as
> draft-ietf-capport-architecture-00.
>
> Thanks!
>
> On 30 August 2017 at 20:03, Erik Kline  wrote:
>> All,
>>
>> As indicated in the minutes from Prague
>> [https://datatracker.ietf.org/doc/minutes-99-capport/], there was a
>> general hum in favor of the architecture document:
>>
>> """
>> 1. for arch doc, do we want a milestone for architecture. Humming: in 
>> favor.
>> 2. is the document a good basis for the milestone? Humming: in favor.
>> """
>>
>> This email is to initiate a two week adoption call for:
>>
>> https://datatracker.ietf.org/doc/draft-larose-capport-architecture/
>>
>> Feedback requested, even if only to restate an opinion expressed in Prague.
>>
>> Thanks,
>> -Erik

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

Re: [Captive-portals] Questions about PvD/API

[Martin Thomson]

What is interesting about Heiko's example here is that this transition
is not necessarily visible to endpoints. Nor can they be forewarned
(assuming they are ignorant of the botnet using their link).
Endpoints were previously on a network without a captive portal, but
one is suddenly interjected.

I see several problems, different for each of the various solutions:

* With 7710 or PvD, the original network would have to be provisioned
with a captive portal, or the switch would happen and the endpoint
won't have a URI to talk to.  That seems relatively tractable,
providing that this didn't lead to a false assumption of captivity
(this is a problem with 7710, I think, because the existence of the
option seems to imply captivity, though this is quite unclear from the
RFC).

* With ICMP, the signal comes from more than one hop away.  An
unmodified router in the home would receive the ICMP message, reduce
the TTL and then it looks like a random Internet host was trying to
deny service.

So running through all the combinations:

7710/PvD + ICMP - you know where to go to get status information and
the network can signal

7710/PvD - ICMP - you know where to go to get status information, but
how would you decide to ask?  Is there some other trigger you would
use?  (This is, I think Vincent's question.)

ICMP - 7710/PvD - you get a signal, but is it legit?  How do you validate it?

Neither - that's the situation we have today.

It seems that there are at least a few people who think that this use
case is in scope.  It doesn't seem materially different from the case
where you run out of bytes (for networks that do accounting that way).
Maybe this use case can inform the design a little better.  Or maybe
someone would like to argue that we don't need to worry about this.



On 25 August 2017 at 06:58, Vincent van Dam <vvan...@sandvine.com> wrote:
> I agree that the information you describe should be pulled from somewhere,
> however, I am more concerned _when_ they should be pulled.
>
>
> In this working group we acknowledged (welcomed) use cases that go beyond
> connecting to a network; the latest example:
> https://www.ietf.org/mail-archive/web/captive-portals/current/msg00455.html
>
>
> If these use cases are indeed in scope; signalling, or a solution that
> allows detection that the walled garden is (re)activated after joining the
> network, need to be in place. The alternative to a signal would be polling,
> or doing some mitm on protocols that allow it. I think both mitm, and
> polling regularly to see if the connection state is walled are bad.
>
>
> Just focussing on signalling (without the semantics/api); I think that
> leaves us with three directions:
>
>
> * descope any solution that would improve the scenario where walled gardens
> are (re-)activated
>
> * accept icmp is a valid direction, and think of a way on how we can use
> this securely in our use-case
>
> * invent a new signal? something the nas is allowed to send to the ue, but
> not icmp?
>
>
> Gr., Vincent
>
>
> 
> Van: Captive-portals [captive-portals-boun...@ietf.org] namens Tommy Pauly
> [tpa...@apple.com]
> Verzonden: donderdag 24 augustus 2017 18:03
> Aan: Lorenzo Colitti
> CC: Erik Kline; Eric Vyncke (evyncke); Martin Thomson;
> captive-portals@ietf.org; David Bird
> Onderwerp: Re: [Captive-portals] Questions about PvD/API
>
> If the client OS needs to add in heuristics to reach a certain volume of
> ICMP messages before trusting them, I think the design is flawed. Beyond
> that, the information we'd like to get isn't just as simple as a boolean
> value that can be aggregated (like unreachable would be). Among the problems
> we're trying to solve for CAPPORT is "how much time do I have left", and
> "when to re-join the portal". Having a source we can query about those
> properties seems to dramatically simplify the flow and trust model. However
> we do things, it seems like this information should be pull-able (even if it
> allows the client to open a connection on which changes are pushed or
> notified) rather than unsolicited pushes of ICMP by the network.
>
> On Aug 24, 2017, at 8:33 AM, Lorenzo Colitti <lore...@google.com> wrote:
>
> It seems to me that any solution involving coordination between two
> protocols is little different, in terms of your criticism that it will lead
> to "a higher rate of misconfiguration", from the PVD solution. (Personally I
> don't think that's a valid argument - saying that if you misconfigure the
> network it won't work well is pretty much a tautology - but you were the one
> that cited that argument in support of the ICMP solution.)
>
> As for several flows, I don't see what would stop an attacker from trying to
> spoof several flows.
>
&

Re: [Captive-portals] Questions about PvD/API

[Martin Thomson]

erent to the
>U-NAPTR input.  To support endpoints that enforce the above
>restriction on URIs, network administrators SHOULD ensure that the
>domain name in the DHCP option is the same as the one contained in
>the resulting URI.
>
>Authentication of a LIS relies on the integrity of the domain name
>acquired from DHCP.  An attacker that is able to falsify a domain
>name circumvents the protections provided.  To ensure that the access
>network domain name DHCP option can be relied upon, preventing DHCP
>messages from being modified or spoofed by attackers is necessary.
>Physical- or link-layer security are commonly used to reduce the
>possibility of such an attack within an access network.  DHCP
>authentication [RFC3118] might also provide a degree of protection
>against modification or spoofing.
>
>A LIS that is identified by an HTTP URI cannot be authenticated.  Use
>of unsecured HTTP also does not meet requirements in HELD for
>confidentiality and integrity.  If an HTTP URI is the product of LIS
>discovery, this leaves Devices vulnerable to several attacks.  Lower-
>layer protections, such as Layer 2 traffic separation might be used
>to provide some guarantees.
>
> Requirements for a Location-by-Reference Mechanism
> https://datatracker.ietf.org/doc/html/rfc5808#page-12
>
>The method of constructing the location URI to include randomized
>components helps to prevent adversaries from obtaining location
>information without ever retrieving a location URI.  In the
>possession model, a location URI, regardless of its construction, if
>made publicly available, implies no safeguard against anyone being
>able to dereference and get the location.  Care has to be paid when
>distributing such a location URI to the trusted location recipients.
>When this aspect is of concern, the authorization model has to be
>chosen.  Even in this model, care has to be taken on how to construct
>the authorization policies to ensure that only those parties have
>access to location information that are considered trustworthy enough
>to enforce the basic rule set that is attached to location
>information in a PIDF-LO document.
>
>Any location URI, by necessity, indicates the server (name) that
>hosts the location information.  Knowledge of the server in some
>specific domain could therefore reveal something about the location
>of the Target.  This kind of threat may be mitigated somewhat by
>introducing another layer of indirection: namely the use of a
>(remote) presence server.
>
>A covert channel for protocol message exchange is an important
>    consideration, given an example scenario where user A subscribes to
>location information for user B, then every time A gets a location
>update, an (external) observer of the subscription notification may
>know that B has moved.  One mitigation of this is to have periodic
>notification, so that user B may appear to have moved even when
>static.
>
>
>
> On Sun, Aug 20, 2017 at 6:34 PM, Martin Thomson <martin.thom...@gmail.com>
> wrote:
>>
>> Hi David,
>>
>> Can you explain more about why you believe that a lower-layer protocol
>> needs to be used?
>>
>> I remember a similar discussion about this about 10 years ago with
>> GEOPRIV.  Then it was asserted that DHCP was the only protocol that
>> could deliver location information to user equipment.  That discussion
>> took a long time, but ultimately ended with an HTTP-based protocol.  I
>> have no desire to repeat that experience.
>>
>> It seems like this is - at least in part - based in how this might be
>> configured.  That is, you believe that a lower-layer protocol offers
>> no option for misconfiguration.  Is that correct?  Have I missed
>> something?
>>
>>
>> On 20 August 2017 at 00:12, David Bird <db...@google.com> wrote:
>> > HI Tommy,
>> >
>> > Agreed that RFC7710 is lacking notification of captive portal existence,
>> > it
>> > only provides configuration information. ICMP would provide the
>> > notification, as it does today for other forms of destination
>> > unreachable,
>> > port unreachable, etc. In your first reply, I thought you were
>> > suggesting
>> > that RFC7710 was at play along side PvD DHCP/RA (and I wasn't clear what
>> > you
>> > meant by DHCP/RA).
>> >
>> > I think we both also agree that taking about both a Capport API *and*
>> > PvD is
>> > adding to the confusion and we ultimately will not want two &q

Re: [Captive-portals] Questions about PvD/API

[Martin Thomson]

Hi David,

Can you explain more about why you believe that a lower-layer protocol
needs to be used?

I remember a similar discussion about this about 10 years ago with
GEOPRIV.  Then it was asserted that DHCP was the only protocol that
could deliver location information to user equipment.  That discussion
took a long time, but ultimately ended with an HTTP-based protocol.  I
have no desire to repeat that experience.

It seems like this is - at least in part - based in how this might be
configured.  That is, you believe that a lower-layer protocol offers
no option for misconfiguration.  Is that correct?  Have I missed
something?


On 20 August 2017 at 00:12, David Bird  wrote:
> HI Tommy,
>
> Agreed that RFC7710 is lacking notification of captive portal existence, it
> only provides configuration information. ICMP would provide the
> notification, as it does today for other forms of destination unreachable,
> port unreachable, etc. In your first reply, I thought you were suggesting
> that RFC7710 was at play along side PvD DHCP/RA (and I wasn't clear what you
> meant by DHCP/RA).
>
> I think we both also agree that taking about both a Capport API *and* PvD is
> adding to the confusion and we ultimately will not want two "APIs".
>
> ICMP today delivers more than hints... it provides signaling that can
> directly influence traffic. Yes, there are security concerns around ICMP,
> which is why it is common for it to be filtered out of networks (which is a
> good think for Capport ICMP, it is only for the edge network).
>
> Regarding ICMP and the "content details of the network" ... I think that
> statement conflates policy and enforcement. ICMP provides (as today)
> notification of enforcement, and RFC7710 provides where to find out about
> the policy (ToS, etc).
>
> The JSON API becomes a "web service" when it has a http(s):// in front of it
> :) .. but, indeed, my concern is in the transport protocol. It being a URL
> signals that this is meant to be deployed alongside the portal, or otherwise
> 'remotely'... Vendors will likely have a "PvD URL: " configuration dialog
> ... and there will be many hotspot services companies updating their "Howto"
> instructions with their PvD URL info... it is a web service.
>
> I welcome suggestions that put that JSON API into a lower layer network
> protocol. We could stuff JSON into ICMP :)
>
> Maybe there is a way to merge ICMP and PvD -- to where ICMP provides the
> notification (with tokens) and PvD provides the policy (based on these
> tokens) (?)
>
> With regard to vendor (NAS/UE) cooperation, perhaps PvD could be a new
> start, but thus far (as my quote of Cisco documentation suggests), it is
> more about what users/venues want. Cisco already today actively avoids iOS
> captive portal detection because the "pseudo-browser" (as they call it) does
> work with their portal. That is a problem that could be solve today by
> Apple/Cisco, couldn't it? Just by not using the pseudo browser...
> introducing PvD doesn't resolve the core problem there, but does make it
> easier to avoid that pseudo browser.
>
> You also said "We can still get to a captive portal once the user goes into
> the browser." ... However, this is increasingly untrue as the work moves to
> https... So, doing this avoidance of detection will still be a problem.
>
> Cheers,
> David
>
>
> On Fri, Aug 18, 2017 at 7:23 PM, Tommy Pauly  wrote:
>>
>> Hi David,
>>
>> My thoughts with regards to RFC 7710 is that it is not deployed as far as
>> I know, and no client stack respects the value sent in 7710. Without some
>> API extensions, it isn't directly better than what we currently have.
>> Ideally, this would not be an API that would get deployed if we were also
>> using PvDs. My concern is that if PvDs are used for enterprise and private
>> networks, we'll have a very similar but less complete path based on RFC
>> 7710. We could end up deprecating or replacing that RFC, which was mentioned
>> in our last meeting. I don't think RFC 7710 can be used without a URL, which
>> is why I think we need a solution that does a better job of indicating the
>> lack of captive or other extended network info.
>>
>> I would hope that since both iOS and Android stack developers are working
>> on the UE side, we would actually see UE deployment of PvDs before any
>> captive vendors adopt PvDs, and we'd be standardizing around Cisco/etc
>> enterprise deployments. By the time there were NAS vendors deploying, they
>> would test with both iOS and Android devices to validate support.
>>
>> Basing our standards on the idea that devices (either networks or UE's)
>> may implement the RFCs incorrectly seems to be a difficult starting point.
>>
>> I like the point you bring up of splitting network notifications from web
>> APIs. There is a need to be judicious about what properties fall into each
>> category. I think you're saying that the fact that there is a captive
>> network can be signaled via 

Re: [Captive-portals] Milestones changed for capport WG

[Martin Thomson]

As discussed, Erik and I have proposed new milestones.  These aren't
yet approved, but I've spoken to Adam about this.  Also, the tool
seems to have made a hash of the notification.

The new milestones will be:

 Aug 2018 - Capture Portal Architecture
 Aug 2018 - API for Captive Portal Interaction

As you can see, we've removed the discovery piece from the API.

As mentioned if we conclude that we're doing something with the ICMP
work - something that is still uncertain - we will revise milestones
at that point.  Expect confirmation of the adoption questions we asked
at the meeting shortly.


On 2 August 2017 at 14:38, IETF Secretariat
 wrote:
> Deleted milestone "Captive Portal Industry Survey".
>
> Deleted milestone "Captive Portal Taxonomy".
>
> Changed milestone "Protocol to discover and interact with a Captive Portal",
> set due date to August 2018 from December 2016.
>
> URL: https://datatracker.ietf.org/wg/capport/about/
>
> ___
> 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] Use Case: "Carrier Grade Captive Portal"

[Martin Thomson]

On 2 June 2017 at 22:47, Livingood, Jason  wrote:
> I’m merely confirming that others share the same use case specified by the 
> German Federal Office for Information Security.

Yeah, I can agree that this is a very common desire.  And I'm glad
that it's the use case that matters, because I believe that the
specific methods you referred to are negatively regarded in many
circles.

The need to send notices with users with whom you don't have an active
communications session is why we developed web push, but that still
requires humans.  The "things" case is tricky, and I suspect that - at
list in the short term - CAPPORT won't have much to offer there.

Though I don't think that we need to abandon hope of finding some
options.  Again in web push we've had some success with voluntary
provision of contact details, see
https://tools.ietf.org/html/draft-ietf-webpush-vapid-02

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

Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal"

[Martin Thomson]

On 1 June 2017 at 08:23, Livingood, Jason  wrote:
> In any case, this is very much in scope IMO – so agree with others here. With 
> the rise of IoT compromises the need for these sorts of notifications will 
> only rise and will be critical to maintaining the security & integrity of the 
> Internet.

Just trying to understand this.  Jason, can you expand on your
assertion that insertion of notices in HTTP messages (I assume
response bodies) is critical to security & integrity?

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

Re: [Captive-portals] Arguments against (any) Capport "API"

[Martin Thomson]

On 7 April 2017 at 22:08, David Bird  wrote:
> To be clear, Gmail hyperlinked boingo.com for me... but, the point is that
> the UE/capport detection parsed and validated (checked the cert and cert
> status) of the FQDN. It is not some URL with questionable formatting...

I think that you missed my point.

The foundation for HTTPS is that there is an expectation of server
identity when navigation is initiated.  The same cannot be said in
this context.

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

Re: [Captive-portals] Arguments against (any) Capport "API"

[Martin Thomson]

On 7 April 2017 at 10:44, David Bird  wrote:
> the more familiar "boingo.com" in the FQDN


You mean boıngo.com ?  Looks legit.


On the larger subject, as a browser person, the real reason for
sandboxing is - I believe - privacy.  One basic security assumption
for the web is that it is easy to cause a user to visit a site.  A
captive portal isn't special in that regard, so I don't credit claims
that sandboxing is a security measure.

The credible reason is that you don't want a user to be tracked (or
de-anonymized) across points of network connection.  That is
definitely a credible story.  You don't want the network using cookies
set by a portal in network A being read by a portal at the same origin
in network B when you just took somewhat extraordinary steps to ensure
that your MAC address was different in both networks.

That doesn't sound like much.  And it is trivially defeated (see
below).  The same user likely visits the same websites from both
locations, but the captive portal has a unique ability to correlate
network-level information (e.g., MAC) with persistent state.  Random
sites on the internet don't have the same access.

The way to defeat this is to wait for an unencrypted HTTP session to
pass.  You can observe tracking cookies and use them to de-anonymize
users. If there are no tracking cookies, then "header encrichment" can
be used to implant a cookie.  We learned at the last meeting that this
is one reason that portals defeat detection: so they can fall back on
this technique.

If the entire web were to use HTTPS exclusively, this method might
stop working.  Or users would have to restrict their cleartext
browsing to a sandbox.  (We've discussed shorter cookie lifetimes for
cleartext origins on the web, but the usability concerns are basically
insurmountable right now.)

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

Re: [Captive-portals] Not good....

[Martin Thomson]

On 2 April 2017 at 17:27, Michael Richardson  wrote:
> One of the things we are going to need to do is to find a way use the
> stick as well as the carrot when it comes to poorly behaved sites.

The big stick I see here is the increased use of HTTPS.  Do we really
need anything more?

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

[Captive-portals] Review of draft-wkumari-capport-icmp-unreach-01

[Martin Thomson]

(As a contributor only.)

David, Warren,

Looking at this draft, I think that there are a few fairly major
changes that this could benefit from.

# Extension payload

The presence of the extension is sufficient signaling for this channel.

If we accept that there will be a protocol for asking the portal for
basic information about connectivity, the UE/device/etc can query that
interface for expiration time.

The warning bit seems dangerous in this context given that it
establishes a non-backwards-compatible behaviour.  To an entity that
doesn't understand this extension, ICMP Unreachable means that the
packet was not forwarded.  I don't think that an extension can safely
change this.

The one obvious caveat for this comment is if we determine that RFC
7710 is insufficient for advertisement of the captive portal URL.  In
that case, we might consider adding the URL to the ICMP message.  I
don't see any evidence that this is necessary yet, and that would
compound the next issue, but it's something to consider.

# Security considerations

There is a fairly direct path between this message and a user visiting
the site identified.  Now, it is well-accepted that it is easy to
cause a user to visit any site, but nonetheless this needs to be
discussed.  We can also offer some suggestions for reducing the use of
this message by arbitrary endpoints.  For example, a device that
receives this message might not act immediately, but instead trigger
portal detection routines before opening a browser.  Those routines
might involve sending more packets and looking for more ICMP
unreachable packets.

For this reason, I think that we should mandate the use of RFC 4884
and a minimum size for the echo of the dropped packet.

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

[Captive-portals] Minutes from capport session posted

[Martin Thomson]

Thanks to everyone for a productive discussion yesterday.

The minutes are here: https://datatracker.ietf.org/doc/minutes-98-capport/

My gratitude to David Schinazi for his excellent minutes.

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

[Captive-portals] Draft Agenda for IETF 98

[Martin Thomson]

I've just uploaded an agenda for the meeting.  Those who are
identified here, please get me your slides before the meeting starts
(ideally before the 26th, for all except the last, which I don't
expect to need a presentation).  Plan on no more than 10 minutes of
presenting so that we can have some discussion and questions while we
also keep to schedule.

https://datatracker.ietf.org/doc/agenda-98-capport/
~~~
Captive Portals (capport, captive-portals@ietf.org)

IETF 98 Chicago
2017-03-28 1450-1620 Zurich D

Administrivia  Chair(s)  10m

Japanese SurveyMariko Kobayashi  15m

draft-larose-capport-architecture-00   Kyle Larose   15m

draft-bruneau-pvd-00   Tommy Pauly   15m

Hackathon Report   Kyle Larose   10m

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

Re: [Captive-portals] Proposals to discover Provisioning Domains (& Captive Portals)

[Martin Thomson]

There's also this terrible idea from an age ago, which like 7710 uses
DHCP: https://datatracker.ietf.org/doc/rfc5986/  Unlike 7710, it
produces a name.

On 13 March 2017 at 07:14, David Bird  wrote:
> HI Tommy,
>
> I agree, there is synergy, particularly as it relates to our desire to have
> a HTTP API like the one in your I-D.
>
> A few high-level comments:
>
> - Could RFC 7710 be used to identify the PvD?
>
> - Do you envision this API being implemented in NAS devices (by vendors) or
> portals (by hotspot web/portal developers)?
>
> - In section 5.3 Reachability, would the client be learning all the
> available resources (e.g. the walled garden)? As a hotspot operator, I would
> probably prefer only giving this information on a need-to-know basis and not
> expose all my partners (advertisers, roaming partners, etc) to every visitor
> upon arrival.
>
> - I believe we could improve (real-time) signaling with capport ICMP (and
> the overall capport architecture)
>
>
> On Sun, Mar 12, 2017 at 12:34 PM, Tommy Pauly  wrote:
>>
>> Hello,
>>
>> I wanted to give the CAPPORT group a heads up about some related work in
>> the explicit discovery of Provisioning Domains (PvDs), that provides one way
>> of discovering and interacting with Captive Portals and other features of a
>> network:
>>
>> Proposals to discover Provisioning Domains
>> https://datatracker.ietf.org/doc/draft-bruneau-pvd/
>>
>> PvDs are a concept from MIF, and before that group closed, one of the open
>> questions was how to discover and communicate explicit information about
>> networks and prefix ranges to a device. We've been working on this with
>> Cisco, Apple, and Google contributors, and we think that there is a lot of
>> potential synergy with the captive portal discovery.
>>
>> The document also goes into various tradeoffs of approaches to getting
>> this information, which is a relevant conversation for how we discover and
>> contact captive portals as well.
>>
>> Please take a read through and let us know your thoughts!
>>
>> Thanks,
>> Tommy Pauly
>> Apple
>>
>> ___
>> 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] FW: New Version Notification for draft-larose-capport-architecture-00.txt

[Martin Thomson]

On 10 March 2017 at 11:12, Dave Dolson  wrote:
> ‎I think a separate draft might be appropriate for the API.

Yep.  I wouldn't expect this doc to get sidetracked too much.

> To take an initial stab at it, we think a GET to the ‎URI provides a JSON 
> document of information and menu choices, since we've heard of a lot of 
> different ideas about how User Equipment might want to navigate the captive 
> portal. Clearly this will need to be standardized.

Agree.  Also, there seems to be some expectation that the URL gets fed
to a browser, so the portal would need to be able to distinguish that
from a JSON document approach.

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

Re: [Captive-portals] Capport project at the IETF 98 hackathon

[Martin Thomson]

Thanks for arranging this Kyle.  I'll be floating around the
hackathon, at least on Saturday and would be happy to lend a hand.

On 3 March 2017 at 03:17, Kyle Larose  wrote:
> Hello everyone,
>
> I've put up some ideas for hackathon projects related to captive portal on 
> the hackathon wiki 
> (https://www.ietf.org/registration/MeetingWiki/wiki/doku.php?id=98hackathon)
>
> * Champion(s)
>o Kyle Larose klar...@sandvine.com
>o Others welcome. :)
> * Project(s)
>o Finish up the icmp I-D 
> (https://tools.ietf.org/html/draft-wkumari-capport-icmp-unreach-01) in 
> coova-chili
>o Try out various client solutions for consuming the icmp message.
>o Try to find security holes in the icmp I-D, and plug them (the output 
> being suggestions to improve the I-D)
>o Work on defining and implementing a REST API for 
> https://tools.ietf.org/html/rfc7710.
>
> I doubt I'll actually be able to work on all of these over the weekend, so if 
> anyone wants to contribute, let me know.
>
> Looking forward to hacking away!
>
> Kyle
>
> ___
> 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] Requests for time in Chicago

[Martin Thomson]

We have a meeting slot set for Chicago.  Right now I have one subject
to discuss.

If you want some agenda time, let me know.

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

Re: [Captive-portals] Feedback requested: Charter text.

[Martin Thomson]

On 9 July 2015 at 07:16, Warren Kumari war...@kumari.net wrote:
 Here is what I currently have.

LGTM.

On 9 July 2015 at 08:46, Yoav Nir ynir.i...@gmail.com wrote:
 I would like the endpoint to be able to authenticate the captive portal 
 (captor? MitM?).

This is a fine secondary requirement; I don't know that it needs to be
part of the charter though.

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

Re: [Captive-portals] Feedback requested: Charter text.

[Martin Thomson]

On 1 July 2015 at 06:13, Tero Kivinen kivi...@iki.fi wrote:
 Which means
 every time I go to the Helsinki Airport, I need to start browser, and
 try to access something so I can click I agree so I can get my
 emails downloading in the background.

That may be a legal constraint.  The network they provide isn't
entirely for your convenience.  That said, one potential mechanism is
one where the portal establishes a cookie that you can use next time
to automatically log in.  Previous visits being perhaps the only
example where automatic login is actually easy.

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