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

["Nancy Cam-Winget (ncamwing)" <[e-mail]>]

Hi Alan, Bernard and Lionel,

Thanks for all the feedback and we can bring the discussion to OPSAWG and realize that we need to clean up the problem statement which we can address in a revision before bringing it to OPSAWG.

Best, Nancy

On 11/17/21, 2:41 AM, "[e-mail]" <[e-mail]> wrote:

    Hi,

    First, it is true that this draft should be rather discussed in OPSAWG, as RADEXT is nearly dead.

    Now, as the discussed has started, I agree with the comments raised by Bernard on the problem statement.

    >From a solution point of view, if the goal of the SMI attribute is to link consecutive authentication phases to the same user using different MAC address, why not just rely on the Acct-Multi-Session-Id used in the accounting messages to link together the multiple sessions?

    Regards,

    Lionel


    Orange Restricted

    > -----Message d'origine-----
    > De : radext <[e-mail]> De la part de Alan DeKok
    > Envoyé : lundi 8 novembre 2021 16:36
    > À : Bernard Aboba <[e-mail]>
    > Cc : [e-mail]; Nancy Cam-Winget (ncamwing)
    > <ncamwing=[e-mail]>; Jerome Henry (jerhenry)
    > <[e-mail]>
    > Objet : Re: [radext] New Version Notification for draft-henry-radext-stable-mac-
    > identifier-00.txt
    > 
    > 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.
    > 
    > _______________________________________________
    > radext mailing list
    > [e-mail]
    > https://www.ietf.org/mailman/listinfo/radext

    _________________________________________________________________________________________________________________________

    Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
    pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
    a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
    Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

    This message and its attachments may contain confidential or privileged information that may be protected by law;
    they should not be distributed, used or copied without authorisation.
    If you have received this email in error, please notify the sender and delete this message and its attachments.
    As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
    Thank you.