Just wanted to chime in to say that I would love to see further work on this draft within EMU, and am happy to provide support from a privacypass perspective
In addition to Joe's points on misbehaving clients, we should be sure to acknowledge to users that this alone doesn't give them privacy, and needs to be combined with other tools as well. Best, Scott On Mon, Dec 16, 2024 at 1: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. > > 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) > - 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. > - 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 > > 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. > > Thanks, > > Joe > > On Wed, Dec 11, 2024 at 9:35 PM Paresh Sawant <paresh_sawant= > 40apple....@dmarc.ietf.org> wrote: > >> Hello EMU WG, >> >> Can you please tell us the next required steps to initiate an adoption >> call for EAP-PPT? We are happy to work on any feedback you have with the >> current draft. >> >> >> Sincerely, >> Paresh Sawant >> >> On Dec 11, 2024, at 11:43 AM, Bart Brinckman (bbrinckm) <bbrinckm= >> 40cisco....@dmarc.ietf.org> wrote: >> >> Hi EMU working group & chairs, >> >> We did take update the draft with all the comments we received before >> IETF121 and did not receive any since. I do believe in order to move the >> draft forward we need working group adoption and thorough review from the >> working group. If a charter update is required, I am happy to help with a >> proposal. >> >> Thanks, >> >> Bart >> >> >> *From: *Michael Richardson <mcr+i...@sandelman.ca> >> *Date: *Tuesday, 3 December 2024 at 16:40 >> *To: *Eliot Lear <l...@lear.ch>, emu@ietf.org <emu@ietf.org> >> *Subject: *[Emu] Re: draft-sawant-eap-ppt >> >> >> Eliot Lear <l...@lear.ch> wrote: >> > I would like to follow-up on discussion from IETF 121. When last >> we left our >> > heros on EAP-PPT, the draft is in reasonable shape but there was >> some >> > question as to whether it was within the charter. If it's not, I >> > propose to >> >> It seems in shape, and I don't understand why it wouldn't be in charter. >> I would rather s/ppt/privpass/ or something. "PPT" is a too-confusing TLA, >> and probably has a trademark against it. >> >> > amend the charter to cover this draft. If it is, I propose that we >> adopt >> > draft-sawant-eap-ppt as a working group item. >> >> >> -- >> Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting >> ) >> Sandelman Software Works Inc, Ottawa and Worldwide >> >> >> >> _______________________________________________ >> Emu mailing list -- emu@ietf.org >> To unsubscribe send an email to emu-le...@ietf.org >> >> >> _______________________________________________ >> Emu mailing list -- emu@ietf.org >> To unsubscribe send an email to emu-le...@ietf.org >> > _______________________________________________ > Emu mailing list -- emu@ietf.org > To unsubscribe send an email to emu-le...@ietf.org >
_______________________________________________ Emu mailing list -- emu@ietf.org To unsubscribe send an email to emu-le...@ietf.org
