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

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



> On Jul 9, 2015, at 5:16 PM, Warren Kumari <[email protected]> wrote:

<snip />

> The CAPPORT Working Group will define mechanisms and protocols to:
> - allow endpoints to discover that they are in such a limited environment
> - allow endpoints to learn about the parameters of their confinement
> - provide a URL to interact with the Captive Portal and satisfy the
> requirements
> - interact with the Captive Portal to obtain information
> such as status, remaining access time, etc.
> - (optionally) advertise a service whereby devices can enable or
> disable unrestricted access without human interaction

This may be covered by the third bullet (sort of...) but I would like the endpoint to be able to authenticate the captive portal (captor? MitM?). This could be done by requiring that the URL be https and that the certificate identify the portal.  For example, I’m typing this while riding a train on my way home. If the captive portal here had a CN or alternate name such as “www.rail.co.il” or “captive-portal.rail.co.il” that would be fine. If it said “CN=acme-initial-certificate,OU=replace-before-deploying,O=do-not-use-in-production” I would be more worried about using it.

I think publicly trusted certificates are now cheap enough that we can require them in (new) captive portals. This is especially important in places like some airports where the portals ask for your credit card number.

I realize this has its limitations. If I go to Frankfurt airport and the certificate says “CN=captive.frankfurtflughafen.de” I don’t know if this is the real domain of the airport or a convincing domain name somebody registered in order to obtain the certificate. But methods to get the right identity can be layered on top of authentication.

Yoav