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

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

<still no hats>

In the abstract we could define the requirements for what could
replace MAC address.  The MAC address is really just a "token" that
the enforcement point adds to the URL and then gets it back from the
API-serving element (AIUI).

It could just as well be HMAC("my c00l secr3t", <client_mac_address>)
which, when passed back to the enforcement point is looked up in some
hash that can expire old entries to find the mapping that identifies
the client.

But that still leaves the issue of how does that "token" get into the
API URL in the first place.  Currently, I have seen what looks like
the enforcement point rewriting URLs to insert this stuff.  I just
think we should be explicit in calling out what we think needs calling
out in this area.  (if for no other reason than it might become
"operational guidance" if someone wants to write such a doc in the

The issue of link-layer token to IP address policy is a somewhat
separate discussion, I feel.  We definitely shouldn't give IPv6 SLAAC
addresses any grief though.  And to me, that points toward the token
being fairly well tied to the link-layer, though of course it can be
made an opaque token (opaque to everything bug the enforcement

On 20 October 2017 at 00:10, Kyle Larose <[email protected]> wrote:
> 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?

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature