Thanks Alexander for reviewing the slides and your thoughtful feedback! Pls see inline.
Thanks, Bart Cisco Confidential From: Alexander Clouter <[email protected]> Date: Friday, 7 November 2025 at 04:10 To: [email protected] <[email protected]> Subject: [Emu] draft-ietf-emu-eap-ppt: refund server reply 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? BART: We can add some wording. I’d rather not mention specific MAC address rotation timeframes, as that may change, but we could refer to RFC9797, which describes the practice and its impacts in detail. WRT Chargeable-User-Identity, it can still be constructed by the IDP. RFC4372 asserts this should be a temporary assertion of identity by the ‘home network’, so in this case the IDP. Since in the case of EAP-PPT it would not be linked to the true identity of the user, but rather be an identifier that represents the ’session identity’ of the user. As such it could be used as a session identification instead of datetime/MAC you propose. This would be inline with how NASes and AAA support Chargeable-User-Identity today, so no new functionality would be needed. If so, is it even possible for the IdP to invalidate any as of yet unredeemed tokens? BART: Yes, the IDP can invalidate unredeemed tokens based on meta-data included in the token, for example expiry, or of course if the public key of the issuer is expired. 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? BART: You bring up a very good point here. Although EAP-PPT was designed to support any token type, Anonymous Credit Tokens use a 2 step process. We did foresee such a 2-step process in EAP-PPT for remediation purposes, but we’ve focused the use of the remediation exchange on a specific use case. We could think of making it more broadly applicable to incorporate potential future use case such as ACT. We will take a look at this. Thanks -- Alexander Clouter _______________________________________________ Emu mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ Emu mailing list -- [email protected] To unsubscribe send an email to [email protected]
