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

Re: [Captive-portals] client identifying info between API and enforcement



Erik Kline <[email protected]> wrote:
    > I was expecting this is what might be required, given the
    > architectures that are currently in use:

I think that I got you, but I need a picture.

    > [3] login service updates enforcement point about token_1's state
    > (assuming login success)

I think that login service updating enforcement point can simply say:
  "allow the L2 address associated with token_1"

If the tokens are big enough (16 bytes or more), they could be the L2 address
encrypted (privately) by the enforcement point, making the enforcement point
stateless.

I think that the access decisions need to be made by the enforcement device
at the L2 level for a bunch of different reasons including auditing.

At this point I think the industry has established that L2-mac-address
randomization is good, but that having it totally random is bad.

It should be the same whenever the ESSID/AP is the same, with some caveats,
and this gets us the nice property that access control doesn't have to be
done every time one visits the same place.

--
Michael Richardson <[email protected]>, Sandelman Software Works
 -= IPv6 IoT consulting =-



Attachment: signature.asc
Description: PGP signature