Re: [Emu] Issue 61 Clarifying NAI handling during resumption

[Alan DeKok <[e-mail]>]

On Apr 11, 2021, at 11:39 PM, Joseph Salowey <[e-mail]> 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.