Just a few thoughts since abuse handling is out of scope. It would be good to see some wording providing guidance that abuse handling is limited to (only?) MAC addresses.
Maybe: ---- Unlike other EAP methods, the EAP-PPT server is unable to link a token back to the identity presented during issuance making construction of a Chargeable-User-Identity, as used by RADIUS, not possible. This limits the abuse handling options available to an operator to observables, namely the presented MAC address of the device that tends to rotate at least once ever 24 hours. ---- I do not know if this would be best served and placed in the security section or maybe a (sub)section on its own. My reasoning is whilst it is right that other methods do not describe abuse handling there is no technical reason that prevents coordination with an IdP to support the medium term blocking of a user. Clearly this would not be possible for EAP-PPT. To handle abuse, is there any value in communicating a datetime/MAC address tuple to the IdP? If so, is it even possible for the IdP to invalidate any as of yet unredeemed tokens? On a related note, you lean on draft-schlesinger-privacypass-act as a possible tool down the road to help out here. My (very!) limited understanding is this effectively returns a new (refund) token upon redemption which is to be used the next time you authenticate. Would EAP-PPT be best extended with a new message type to continue a challege/response or do you think this would be best implemented as a non-fatal PPT-Error with a 'refund' key smuggled in the response? Thanks -- Alexander Clouter _______________________________________________ Emu mailing list -- [email protected] To unsubscribe send an email to [email protected]
