Re: [radext] New Version Notification for draft-henry-radext-stable-mac-identifier-00.txt

[Alan DeKok <[e-mail]>]

On Nov 8, 2021, at 10:25 AM, Bernard Aboba <[e-mail]> wrote:
> The problem is not clearly stated.

  Agreed.

> There are issues created by changing MAC addresses that could affect the user experience. The document mentions mapping of the MAC address to assigned IP addresses.

  " Continuity might include for example obtaining the same IP address from the DHCP server"

  If the same IP is assigned based on SMI and not RMC MAC, then that sort of negates the reason to use random MAC addresses.  You can tell it's the "same" machine, because it has the same IP address.

> I would note that the point of randomized MAC addresses is to reduce the ability to track users and devices. EAP supports both machine and user authentication and lately there have been efforts to protect those identifiers from exposure in clear text so as to limit tracking. Presumably similar concerns would exist about any machine identifier.  

  I see it as useful to have a unique device identifier, which is visible only to the device and to the RADIUS server.  Ideally, this identifier shouldn't be visible to anyone else in the network. 

 The document implies that changes will need to be made to the Ethernet / radio layer:

  "Additionally, once a protected link has been established between the client and the AP/WLC, as in 2.1, the client requests from the NAS a stable identifier or provides to the NAS a stable identifier."

  This process requires involvement from the IEEE, in addition to the IETF.  I'm not sure why using a stable identifier requires changes to the lower-layer protocols.

  TBH, the identifier could just be put it in a TLS extension.   Require TLS 1.3 for security, and that's it.  Have the device generate a random 128-bit identifier.  No negotiation is necessary.

  A similar method is already being proposed in https://datatracker.ietf.org/doc/html/draft-friel-tls-eap-dpp-01

  Alan DeKok.