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

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



Is another way of looking at this problem to consider defining the identity of the user equipment?

From the perspective of the enforcement device, it's probably the source MAC address or source IP (or both) of the packets being sent through it. It's hard to spoof that without wrecking the network, right?

But, if we intend on having the API server potentially live elsewhere in the network, those identifying characteristics may not be available in the requests being sent to that server, or if they are, they may be different due to intermediate devices such as NAT, routers, etc.

If the user equipment understands its identity, then it can always put that into requests. As long as everyone agrees on what constitutes the identify, we're good. That sort of aligns with my earlier email about potentially negotiating what identifies a user equipment.

However, what concerns me with this approach is security: how can we trust that the client of the API server isn't spoofing its identity? So, the question becomes: what verifiable identify can a user equipment have that an API server can validate, and if necessary, translate into an identity understood by the enforcement device?


-----Original Message-----
From: Erik Kline [mailto:[email protected]] 
Sent: Monday, October 16, 2017 8:20 AM
To: Kyle Larose; Dave Dolson
Cc: [email protected]; David Bird
Subject: client identifying info between API and enforcement

<hat-free />

Kyle, Dave, (David, all,)

When a client is trying to talk to an [architecture-2.3] API server,
using the URL is learned in [architecture-2.2], will it need to
present some token that the API server can ultimately use when
communicating back to the enforcement box?

I'm effectively wondering about how we get (something like) the MAC
address of a client into this URL, /especially/ when the URL might not
be custom crafted for each client (i.e. in the case of the URL in an
ICMPv6 RA or learned via PvD mechanics).

What's required here and how do we think it should work?