[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Captive-portals] Starting to discuss Captive Portals



Is there any sense in moving to .well-known for this?  That would
allow for a status check resource, which would avoid some of the
jankiness of other options.

On 30 March 2015 at 14:07, Warren Kumari <[email protected]> wrote:
> 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
>
> _______________________________________________
> Captive-portals mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/captive-portals