Hi Michael,
Thanks for your support!
The NAI realm is required to route to the AAA that terminates the outer
EAP-method, which is typically the same AAA that supports the inner EAP method.
For EAP-PPT this is the AAA that can perform verification of the Privacy Pass
token. In order to perform verification of the Privacy pass token, the public
key of the issuer is required (depending on the token type). Therefore we
recommend that the AAA server terminating EAP-Phase 1 is not in the home
network. It can be in the visited network or a 3rd party service.
There are recommendations around unlinkability of the tokens in section 6.5
which discussed privacy and in the privacy section of the deployment
considerations (section 10.1). I’ll go through this text again to make sure
this is clear. Let me know if you have any recommendations.
Thanks!
Bart
From: Michael Richardson <mcr+i...@sandelman.ca>
Date: Saturday, 12 April 2025 at 23:15
To: EMU WG <emu@ietf.org>
Subject: [Emu] Re: Adoption Call for draft-sawant-eap-ppt
I support doing work on EAP with Privacy Pass Tokens.
I'd rather we didn't call it PPT: it will confuse muggles.
I don't understand how the token keeps the visiting network from knowing the
identity of a user, if the NAI is required in order to route the EAP to the
home network. The document says that the token can only be used as an inner
method, that it should be within an EAP-TLS mechanism. (I assume EAP-TEAP
would also work)
--
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
