[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Captive-portals] Starting to discuss Captive Portals
On Mon, Mar 30, 2015 at 7:41 AM, Patrick McManus <[email protected]> wrote:
> I really appreciate the draft.
>
> There is one thing I really like about the draft, as it operates at a dhcp
> level the first hint I'm in a CP happens strictly before any connections are
> formed.. that should help keep things orderly without imposing delays on
> non-CP scenarios. Unfortunately, because it doesn't help with CP state (just
> CP enabled network or not) it does add delay for determining state with
> some, potentially slow, internet server for hosts behind CP that are already
> whitelisted. For instance, every time I open my laptop in a hotel for 24
> hours after signing the T&C.
>
> I also agree with Yaron's thoughts. I think the document acknowledges a few
> problems that it needs to actually deal with to make this practical
>
Fair. I'm (always) happy to accept suggestions on how to address
these... and, of course, even happier to get text :-)
> * Capture status
How about something like requiring that the "Congratulations, you are
now connected to the Internet" page contains a magic string (e.g:
"CP_SATISFIED_JABBERWOCKY" or "The Magic Words are Squeamish
Ossifrage") ? This allows the client to know when it has satisfied the
Captive Portal.
> * expected TTL to facilitate orderly renewals - surprise renewals are a real
> pain point.
How about simply adding a TTL field to the DHCP / RA that lists the
TTL in seconds (or minutes) of how often the client should come back?
One potential issue is that many captive portals give you different
options -- 1 hour for $9.99, 24 hours for $19.95. We could define
another protocol that the client could use to interrogate the CP (in
which case I'd think we could punt this to the grand unified theory
document), or perhaps the "Congrats" page could also include the time
purchased. Or, we could define a well known endpoint on the same URI
that speaks something REST like.
Yes, I know not everything is the web (thank gods!) -- but, let's face
it, for most of the current captive portal scenarios there is an
expectation that users have a browser...
> * Some kind of authenticable token, separable from the DNS in a https:// CP
> url, that clients might whitelist or prioritize (perhaps from history)
Huzzahwhat? I'm sorry, but I have no idea what this means... The
client gets some sort of authentication cookie that it can present
back to the CP in the future to prove that it has already
authenticated? Something else? Sorry, not a clue....
> * how https:// uris deal with revocation (i.e mandate in-band, or mandate
> whitelisting of revocation check, etc..)
>
Oooh. This could get really tricky -- at the moment browsers already
have all sorts of interesting strategies to do, or not do, revocation
checking. This gets even weirder in a world where you are behind a
captive portal.
This has bitten a number of people a number of times. I'm managed to
purge much of this from my brain, but back in ~2011 Apple released
(IIRC) 10.7. This did the "obviously" right thing of doing OSCP
checking and refusing to continue until it got a response --
unfortunately this simply doesn't work from behind most captive
portals.
Actually, many browsers simply don't do revocation checks in the way
the people expect them to -- the classic understanding is that
"browser gets a certificate. It does an OSCP check and / or checks all
of the CRLs to see if the cert is revoked. If it is NOT revoked, it
continues". In the real world, things are, um, messier.
See for example: https://www.imperialviolet.org/2014/04/19/revchecking.html
Opening the revocation can of worms^w spiders is, IMO, a dangerous
idea, and puts me in mind of:
https://www.youtube.com/watch?v=2RyTp-rC2VQ
One thing that I'd like to try and keep is the simplicity -- I'd much
rather have a document that "mostly works, most of the time" completed
in less than a year in favor of an all singing, all dancing, fully
complete solution that solves everyone's problems....but never gets
finished.
Anyway, we've been working on this document since Jan 2014, and most
of the problem has been getting reviews -- I'm really glad that a: the
general CP issue is now being looked at and b: this document is
getting some (much needed) review.
Thanks, W
>
>
> On Mon, Mar 30, 2015 at 12:42 AM, Yaron Sheffer <[email protected]>
> wrote:
>>
>> So, here's a few thoughts:
>>
>> I suggest to add a requirements section. The reasons why other methods
>> suck (Sec. 2) would be a good start, but I suspect there will be additional
>> requirements once a bigger audience looks at this.
>>
>> I suggest to add an example scenario, such as: Jean goes into a coffee
>> shop. She signals her agreement to the usage terms and fires up her VPN.
>> After an hour, the session expires, and she needs to click "agree" again.
>>
>> When we add such a scenario, we will most likely recognize that the DHCP
>> option is not sufficient for what we need, even for a basic CP. The document
>> currently even does not define how applications (the browser, other
>> browsers, a mail client, VPN client etc.) can detect that the CP is now
>> "open", let alone reliably detect when it has "closed" again. We should not
>> rely on the legacy detection methods for this, or we will never get rid of
>> them.
>>
>> Thanks,
>> Yaron
>>
>>
>> On 03/29/2015 07:31 PM, Mark Nottingham wrote:
>>>
>>> Hi everybody,
>>>
>>> Thanks to those that came to the Bar BoF in Dallas. Feel free to
>>> introduce yourselves here.
>>>
>>> I think the strongest outcome there was the interest in the draft for a
>>> new DHCP option:
>>> http://tools.ietf.org/html/draft-wkumari-dhc-capport
>>> IIRC Joel said he was considering sponsoring this document; it would be
>>> great to get feedback from OS vendors if they haven't seen it yet.
>>>
>>> Hotspot 2.0 <https://en.wikipedia.org/wiki/Hotspot_(Wi-Fi)#Hotspot_2.0>
>>> has been brought up by a few people as well. AFAICT, it's focused on
>>> "roaming" use cases — e.g., allowing mobile carriers to offer wifi services
>>> seamlessly. That's interesting, but AIUI not applicable to *many* use cases
>>> where captive portals are used.
>>>
>>> Thoughts?
>>>
>>> The wiki we've been using to keep state is here:
>>> https://github.com/httpwg/wiki/wiki/Captive-Portals
>>> Feel free to edit, and if it gets unwieldily, we can consider moving it
>>> out of that space.
>>>
>>> Cheers,
>>>
>>> --
>>> Mark Nottingham https://www.mnot.net/
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Captive-portals mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/captive-portals
>>>
>>
>> _______________________________________________
>> Captive-portals mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/captive-portals
>
>
>
> _______________________________________________
> Captive-portals mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/captive-portals
>
--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
---maf