On Apr 11, 2021, at 11:39 PM, Joseph Salowey wrote:
> Alan's review raised the issue that the text allows for different identities
> to be used for the initial handshake and subsequent resumption. Instead the
> proposal is to always use the same NAI for resumption as for the initial
> handshake.
>
> I'd like to understand the reason for this concern. It seems like this would
> make things worse from a privacy perspective unless we also required the NAI
> to just be @REALM which is the minimum amount of information that can be
> disclosed and still have the current system work.
That was my proposal.
The underlying question is: What identity should be used in the EAP-Response
Identity packet?
This identity should be accessible to the EAP peer, which pretty much rules
out any TLS PSK resumption identity. (the OpenSSL APIs don't give any simple
way to extract this from the TLS session)
This identity should be routable in a roaming system, which also rules out
the TLS PSK resumption identity.
This identity should not disclose private information, or allow observers to
correlate sessions. This means that it should either be consistently empty,
but compatible with roaming and therefore "@realm". Or, the identity should be
an opaque identifier which changes for each session.
However, there is no way in EAP-TLS to negotiate a changing identity. Which
means that it will just be an opaque blob invented by the peer, with no meaning
to the authenticator.
There is one other piece of public information which is unique to the decide:
the Ethernet MAC address. This is already visible locally to anyone who can
monitor the EAP traffic. And, visible to anyone who can see the upstream
RADIUS traffic, as that MAC is placed in Calling-Station-Id.
But do we really want to recommend using a MAC address as an EAP identity?
What would that gain us?
So... we're left with "@realm". Not be because it's the best, but because
pretty much everything else is wrong. And, we know @realm works, because it's
already been working with EAP for a decade.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
