Thanks Alan,
Some more comments inline.
From: Alan DeKok <al...@deployingradius.com>
Date: Monday, 16 December 2024 at 10:09
To: Joseph Salowey <j...@salowey.net>
Cc: Paresh Sawant <paresh_saw...@apple.com>, emu@ietf.org <emu@ietf.org>, Bart
Brinckman (bbrinckm) <bbrin...@cisco.com>
Subject: Re: [Emu] draft-sawant-eap-ppt
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.
{BART} The visited network will know the redeeming AAA, the outer identity will
be decorated with its realm. The Identity provider (Attester in privacy pass)
remains anonymous to the visited network.
> - 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.
{BART} The redeeming AAA is trusted to the visited network, and will
authenticate the user by verifying the signature on the token. The identity
provider is not involved in the AAA exchange, so I believe there is anyonimity
both ways. The visited network does not know who the identity provider is and
vie versa, the identity provider does not know that the user is visiting the
network.
> - 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
