Hello, On Wed, 23 Jul 2025, at 16:00, Alan DeKok wrote: > > The device will generally be using the same Calling-Station-Id for > multiple sessions to the same SSID. That puts a strong limit on how > much privacy is available.
The issue is this method requires machinery to deal with bad actors. Otherwise it should include wording telling visited site operators that other than blocking an entire realm, their options are limited. > But to your point, yes, the home server should send a > Chargeable-User-Identity. For EAP-PPT this is not even possible as it would be completely decoupled from the user. Communicating the CUI back to the IdP is meaningless as it also has no idea. >> I understand the entire purpose of the draft is to prevent associating one >> user session from another, but as this draft stands, a bad actor could >> deliver service impacting effect and the site operator would be powerless to >> prevent them re-connecting; other than to block *all* visiting users from >> that IdP realm. > > CUI doesn't help here. It's often unique per session. So the > visited network can't track it across multiple sessions. For a federation, this is a policy issue, not a "it cannot be done". > This is a separate problem, I think. Other EAP types have the same > issue. But it's a problem which should be addressed. No, this is precisely the problem, other EAP methods do not have this issue. For other EAP methods the IdP knows the user connecting so it is simply policy on how Chargeable-User-Identity is formed if at all. With EAP-PPT, the IdP has no idea who is connecting and has nothing to so cannot create this even if they wanted. This is a pretty unique feature of this method, it really is the reason this method exists at all. I have no idea how to solve this but I was sitting in on the Privacy Pass WG meeting shortly after EMU and it turns out they literally are talking about this problem and how to tackle it. https://datatracker.ietf.org/doc/slides-123-privacypass-anonymous-credit-tokens/ They are though at the spit balling stage. Of interest to operators, they are also looking at how to return signally tied back to "amount of resource consumed" as well as abuse signalling. Cheers Alex _______________________________________________ Emu mailing list -- emu@ietf.org To unsubscribe send an email to emu-le...@ietf.org
