Re: [Captive-portals] customizing API URLs vs ???

[Nicolas Mailhot <[e-mail]>]

Le mercredi 31 juillet 2019 à 17:00 -0400, Michael Richardson a écrit :
> Nicolas Mailhot <[e-mail]> wrote:
>     >> It probably occurs less in places like airports, hotels and
>     >> enterprises where there is more local operational clue.
> 
>     > In entrerprises the dhcp layer is mostly owned by desktop IT
> (ADs, in
>     > the hands of people still stuggling to come to terms with the
> way
>     > Microsoft adopted networking and the cloud with a vengeance)
> while
>     > access to the internal network (or from the "safe" internal
> network to
>     > the wild internet, or from low-security visitor networks to
> high-
>     > security internal networks) is managed by network or security
> teams.
> 
> I'm not sure why you are bringing up desktop IT when I mention
> DHCPv4.
> In an enterprise captive portal use, I would expect it would be for
> visitors.

There are lots of nuances in enterprise IT, it's not the binary
access/no access of a coffee shop. What computers are allowed to do and
see before the portal dialog is successful can vary wildly.

Plus, the bigger the org, the harder it is to make people work
toguether. There will be silos because humans can not stop themselves
from playing politics.

> What is your preference: does the client API have to have the client
> self-identify, or do we have to find a way to send unique URLs in
> IPv6 RAs?

The most robust solution would be for the client to be aware of the key
used by the infra to id its access. That may be a mac, or an IP, or (if
the http workgroup could get its act toguether) a token given to a
proxy gateway in a specific proxy-oriented http2+ frame to let things
pass through. That all depends on the network topology and the point
and protocol level at which gating occurs.

So basically you want the portal to tell the client "ok with this ID".

That means the client must send the correct kind of id in a http header
first.

So, probably:

1. define a rejected id portal message, with a field containing the
kind of id it expected (ip, mac, whatever, an unconstrained list with
some usual values defined in the rfc)

2. require the client auth request to contain a field with the proposed
id kind (matching the field in reject) and another with the id value

And then the client can either send the most usual kind of id to a
portal it knows nothing about, hoping to save a roundtrip, or send a
bogus kind of id, to learn what the portal expects, making privacy guys
happy. It becomes client policy the RFC needn't concern itself about.

Anything else will just set in stone a specific network architecture or
policy.

Field can be an http header of an xml/json/yaml field in the body. The
only thing that is sure to be encrypted, making privacy guys happy,
especially if the portal is very very far away from the gating point,
is something in the body.


Regards,

-- 
Nicolas Mailhot