On Dec 16, 2024, at 7:07 AM, Joseph Salowey <j...@salowey.net> wrote: > Sorry for the delay. The EMU charter is pretty tight so this may not be > covered, however if we agree on the problem we are trying to solve, which we > need to do anyway, then updating the charter isn't much of an issue.
There's some overlap with EAP-FIDO, but I think there's interest in doing both methods. > Here is an initial stab at the problem > > An EAP method that provides additional privacy by preventing a visited > network from knowing the identity of a user and for the home provider from > tracking what networks a specific client is using. > > Some things that we are not trying to solve for: > > - Providing a mechanism directly associated with the EAP method to identify a > misbehaving client so it can be excluded from the network (other information > such as MAC address is not related to this exchange and could be used) > - others? > > Things that may be open issues: > > - Does the visited network need to know who the home provider is? (it seems > it would be better privacy if it didn't) It's likely a business requirement that the visited network knows who the home provider is. It's also likely an AAA routing requirement. i.e. if the outer realm is completely anonymous, then it isn't routable. See RFC 7542 on routing in an AAA infrastructure. > - What information does the home provider get (if any) - for example today > things like client MAC address may be sent through the AAA call chain - while > this is somewhat outside the EAP method it seems like this could negatively > impact the privacy of this use case. Yes. While EAP provides for some privacy, the MAC and much other information is exposed in the RADIUS packets. Anonymizing that information would involve significantly more work. Off of the top of my head, the only way to fully anonymize all access would be via a trusted intermediary. That intermediary would terminate the RADIUS layer and the EAP-TLS tunnel, then forward the inner EAP-PPT data somewhere else over RADIUS. But that is not a trivial thing to do. > - THe client needs to get a privacy pass token over a different interface or > have tokens cached if they don't have one and need network access Yes. > Proposed mechanism > > - the proposal is to use a mechanism similar to RFC 9577 as an EAP method > where the client already has a privacy pass token issued from an issuer > acceptable to the server. The server sends a challenge and the client > generates an untraceable token from the challenge and the issued token to > send to the server to verify. > > > Some initial comments on the document > - I dont think EAP-PPT generates key material, it requires the tunnel method > to generate key material as the privacy pass exchange does not result in > shared keys > - Since EAP-PPT does not generate keys channel binding is of limited value. Yes. Alan DeKok. _______________________________________________ Emu mailing list -- emu@ietf.org To unsubscribe send an email to emu-le...@ietf.org
