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

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Mon, 8 Nov 2021 03:21:32 +0000

Hi all,
We have submitted a draft that relays a stable MAC identifier to the RADIUS server.  The identifier is being defined by 802.11 as they implement MAC address rotation.
Your reviews and feedback are being solicited as we would like to see this work move forward here as well.

Best, Nancy

On 10/11/21, 12:31 PM, "[email-masked]" <[email-masked]> wrote:

    A new version of I-D, draft-henry-radext-stable-mac-identifier-00.txt
    has been successfully submitted by Jerome Henry and posted to the
    IETF repository.
    
    Name:		draft-henry-radext-stable-mac-identifier
    Revision:	00
    Title:		RADIUS attributes for Randomized and Changing MAC addresses
    Document date:	2021-10-11
    Group:		Individual Submission
    Pages:		14
    URL:            https://www.ietf.org/archive/id/draft-henry-radext-stable-mac-identifier-00.txt
    Status:         https://datatracker.ietf.org/doc/draft-henry-radext-stable-mac-identifier/
    Htmlized:       https://datatracker.ietf.org/doc/html/draft-henry-radext-stable-mac-identifier

    Abstract:
       This document describes the means by which a Stable MAC address
       identifier can be signaled to a Authentication Authorization and
       Accounting (AAA) server.

    
    The IETF Secretariat

---

From: Alan DeKok <[email-masked]>
Date: Mon, 8 Nov 2021 09:05:49 -0500

> Your reviews and feedback are being solicited as we would like to see this work move forward here as well.

  As RADEXT is essentially dead, I think the way forward is to submit the draft to OPSAWG.  I'll support it there.

  I have some comments on initially reading the document.  Mostly clarifications, and asking for more details.  Over all, I think this work should go forward with some rework.

Section 2:

  The attributes in this document are intended to be applicable across
   a wide variety of network access scenarios in which RADIUS is
   involved: * In some cases, ...

It appears that the "*" was intended to be a separate bullet item?

   The client may then have not provided a stable
   machine identifier (SMI) to the RADIUS server, for example because
   the 802.1X/EAP process authenticated the user.

I'm not sure how 802.1X/EAP authentication causes the identifiers to be unstable.  The two things would seem to be completely independent.

   *  There are cases where the client may express a machine identity to
      the RADIUS server during the authentication phase, and that the
      RADIUS server interprets as stable, but may not express a stable
      machine identifier to the NAS.

The client's interaction with the RADIUS server is mediated by the NAS.  So there's not many ways that a client can "express" an identity to the RADIUS server without the NAS also seeing that information.  Hopefully this is explained later in the document.

And nit: "express" doesn't seem correct here, despite being used throughout the document.  Perhaps "inform" would be a better choice.  The client doesn't express an opinion, for example.  It informs the RADIUS server of something.

Section 2.1:

   In this scenario, the client initially joins the network in a
   constrained state and proceeds through the 802.1X/EAP authentication
   phase. 

Nit: If the client hasn't authenticated, then it hasn't "joined" the network.  And the use of "constrained state" here does follow typical terminology.

  ...  This characteristic is visible to the
   NAS (in the client source address) a

Nit "characteristic" here seems unnecessarily complex.  Perhaps just "information" again.

   ... The RADIUS validates the user identity
   (but not a stable machine identity). 

Perhaps: The RADIUS validates the user identity, but cannot validate the machine identity, as no stable identifier is available at this point.

2.1.1.  General Use Cases
 
   ...

It would be worth noting that the RCM MAC address MUST NOT change when the device uses session resumption for EAP.  If the MAC changes, then it looks like the resumption data has been sent to a different device, which would be a security breach.

In addition, if the RCM MAC address does change, then the device MUST re-authenticate from scratch, and not use any cached session resumption information.

  ... If the
   wireless infrastructure (NAS) receives a stable machine identifier
   information from the client, after authentication with the client
   first MAC address, then the NAS SHOULD share this identifier with the
   RADIUS server.

Nit: perhaps add "via the following process"

   Thus, after the NAS has received a stable identifier representation
   from the client machine, the NAS SHOULD send a new access-request
   message to the RADIUS server.  

Containing... what?  There's clearly more than just a SMI attribute in the packet.

   The Calling-Station-ID is the current RCM MAC
   address.  If the STA is requesting the SMI, the SMI payload SHOULD
   set to Null.

There is no concept of "Null" in RADIUS.  RFC 2865 says that zero-length attribute MUST NOT be sent.

Perhaps instead say "the 48-bit value of all zeros is special, and indicates that the client is requesting a SMI.  And remove all references to "Null" in the document.

   The RADIUS server supporting the SMI attribute considers the
   authentication as already validated and SHOULD returns an Access-
   Accept message. 

Again: how?  What's in the Access-Request packet?  

   If the NAS request had the SMI AVP set to Null and the RADIUS server
   did not uniquely identify the client machine, then the RADIUS server
   SHOULD return an Access-Accept message with the SMI AVP set to the
   Null value.  The NAS then generates a local SMI for the client, and
   sends it to the client machine over a protected frame on one hand,
   and to the RADIUS server as above on the other hand.

Lots of questions here... how does the RADIUS server uniquely identify the client machine?  How does the NAS send the SMI to the RADIUS server?

The rest of this section gives a very high level overview of what happens.  I have similar comments as above: the requirements are high level, and vague.

2.1.2.  Special scenarios

   ... In cases 2 and 3, when the
   client changes its MAC address and the infrastructure immediately
   recognizes the new MAC address as representing the same machine as
   before, no client MAC address change occurs from the perspective of
   the other infrastructure systems.

Except that the MAC address is seen in the RADIUS accounting packets?

    ... It is only
   when a new stable machine identifier is expressed between the NAS the
   other infrastructure elements that a new SMI exchange is needed
   between the NAS and the RADIUS server.

It's not clear why the Stable Machine Identifier would change?  If it's changing, why is it "stable"?  If it's stable, why is it changing?

I have similar comments about the RADIUS exchanges as above.

2.1.3.  Failure Handling

   ...    The RADIUS server not supporting the SMI is unable to process the
   request and SHOULD respond with an Access-Reject, a NACK, or SHOULD
   NOT respond. 

Which one is it?  And it's very bad to suggest that the RADIUS server should not respond to a packet.  Very, very, very, bad.

   Additionally, the RADIUS server may detect an anomaly in the SMI
   (format error, duplication, suspicion of impersonation or other
   malicious detection).

How is this done?  Especially because the SMI can change.  So is the change allowed, or is it impersonation?

  The RADIUS server may then return to the NAS a
   warning in the form of a VSA, thus causing the NAS to reject or
   contain the offender.

Details, please.  This suggestion seems very much outside of the traditional way of doing things.

2.2.  Stable RADIUS machine identifier

   Some methods use RADIUS to authenticate the client machine itself,
   irrespective of the user authentication. 

Some methods of... what?  RADIUS just carries authentication information.  It has no concept of machines versus users.  So the description here needs more explanation to describe precisely what is being discussed.

   In that case, the RADIUS
   server receives a stable identifier for the machine, even when the
   MAC address and the associated Calling Station-Id are changing.

A stable identifier in the form of... what?  Details, please.

3.  Stable-Machine-Identifier

   ...

Nit: suggest a minimum length, and a maximum length.  48 bits is likely too small.  256 bits is enough to uniquely identify every atom on the planet.

5.  Security & Privacy Considerations

   It is strongly recommended that the SMI format used is such that
   neither the machine globally unique MAC address nor the machine user
   identity are revealed.

Are there suggestions for how this is to be done?

   ... Furthermore, where a reference is used to the
   machine globally unique MAC address or to the machine user identity,
   it is recommended that the binding lifetime of that reference be kept
   as short as possible.

I'm unclear on what that means.  What is a "reference" to a MAC address?  The rest of the document doesn't mention references to MAC addresses.

   Attempting theft of service, a man-in-the-middle may try to insert,
   modify, or remove the SMI in the Access-Accept packets and Accounting
   packets.  However, RADIUS Access-Accept and Accounting packets
   already provide integrity protection.

This is true of all RADIUS packets, no matter their content.  It's not clear why this needs to be called out specifically for SMI.

   If the NAS includes SMI in an Access-Request packet, a man-in-the-
   middle may remove it.  This will cause the issues that the SMI was
   designed to solve.  To prevent such an attack, the NAS SHOULD include
   a Message-Authenticator(80) attribute within Access-Request packets
   containing a SMI attribute.

RFC 5080 Section 2.2.2 already says:

   Client implementations SHOULD include a Message-Authenticator
   attribute in every Access-Request to further help mitigate this
   issue.

It would be worth referring to previous standards, and re-iterating their security requirements.  There isn't much need to repeat a lot of previous text about how bad RADIUS security is.

The Security Considerations section here should also discuss security issues with the SMI, how it's used etc.  See comment below for some discussion on this topic.

Summary:

  The document discusses high level concepts, and is vague on details.  We need SMI, but the current text isn't clear enough for me to implement anything.

  I don't think the SMI negotiation belongs in an Access-Request exchange.  I'm not sure how that would work.  The details are very high level.  It's not clear how this would work with proxies.  There are many open questions.

  It would be simple to just do the following:

* if the device doesn't have an SMI, it creates one.  Perhaps a 128-bit random identifier would be sufficient to avoid collisions

* the device then informs the NAS as to what the SMI is.

* the NAS puts the SMI into RADIUS Accounting-Request packets for a particular session

* the RADIUS server sees the SMI, and correlates it with the RCM MAC

* if the SMI is available during the original authentication, the client device informs the NAS, and the NAS places the SMI into the Access-Request packets.

  There's little need to involve the RADIUS server in the SMI allocation / assignment.  If the RADIUS server can't already identify the device, then there's no reason for the RADIUS server to assign an SMI.  The client device might as well do that.

  In addition, it would be useful for the device to have a different SMI for each realm it is authenticating to.  i.e. when authenticating as "[email-masked]", it would send SMI 1234.  When authenticating as "[email-masked]", it would send SMI 5678.  This process would ensure that organizations could not cooperate to remove device identity.  And it means that leaks of user/device databases would not permit attackers use the SMI for correlating users across multiple organizations.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 8 Nov 2021 10:25:31 -0500

I have some very basic questions about the document.

The problem is not clearly stated.

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. There are also potential problems created in mapping keys to MAC addresses. This could potentially interfere with handoffs within a controller or between controllers, and perhaps require re-authentications, increasing RADIUS server load.  It would help to have a succinct problem statement identifying the problems that this document is trying to solve. 

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.  

> On Nov 8, 2021, at 09:06, Alan DeKok <[email-masked]> wrote:
> 
> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext

---

From: Alan DeKok <[email-masked]>
Date: Mon, 8 Nov 2021 10:35:38 -0500

> 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…

  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.

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 16 Nov 2021 15:01:08 -0800

Hi Nancy,

Bernard's question touched on this as well, but I was curious how this
relates to the work ongoing in the MADINAS WG?

Thanks,

Ben

---

From: <[email-masked]>
Date: Wed, 17 Nov 2021 10:41:07 +0000

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 <[email-masked]> De la part de Alan DeKok
> Envoyé : lundi 8 novembre 2021 16:36
> À : Bernard Aboba <[email-masked]>
> Cc : [email-masked]; Nancy Cam-Winget (ncamwing)
> <ncamwing=[email-masked]>; Jerome Henry (jerhenry)
> <[email-masked]>
> Objet : Re: [radext] New Version Notification for draft-henry-radext-stable-mac-
> identifier-00.txt
> 
> > 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.
> 
>   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.
> 
>   "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.
> 

_________________________________________________________________________________________________________________________

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.

---

From: "Jerome Henry (jerhenry)" <[email-masked]>
Date: Wed, 17 Nov 2021 13:33:42 +0000

Good morning Benjamin,

(disclaimer: I am not Nancy __)

This works somewhat relates to MADINAS, in that both stem from the fact that personal devices have started randomizing their MAC address (RCM)when they connect to (wireless) networks. This changed behavior causes the failure of multiple assumptions that have been made over the past 3 decades on the idea that one client = 1 MAC. In the case we address in this draft, we look into bringing back stability in the exchanges between an authenticator (AP/Wireless LAN controller) and RADIUS, when one side or the other gets a stable identifier (I fully agree that the context is not clear in the draft, we'll expand it).
MADINAS also looks at the consequences of RCM, but their charter does not allow for the development of new protocols (or updates of existing RFCs defining a protocol). Their scope is to examine the consequences of RCM (so they will likely also observe the problem we observed and started from in this draft), but they can then only make best practice recommendations, or suggest that other groups might want to help solve the problems they identified.

All the best

Jerome 

On 11/16/21, 6:02 PM, "Benjamin Kaduk" <[email-masked]> wrote:

    Hi Nancy,

    Thanks,

    Ben

---

From: "Jerome Henry (jerhenry)" <[email-masked]>
Date: Wed, 17 Nov 2021 14:43:41 +0000

Good morning Lionel,

Thanks a lot for providing feedback.

Fully agree on the right forum and the problem statement (we'll improve the problem statement and will suggest review in OPSAWG).
On the Acct-Multi-Session-Id, we indeed initially considered this possibility. However, we found that it suffered from several limitations (of course, we could also propose to extend Acct-Multi-Session-Id, but the backward compatibility would become a challenge), among others that it is intended to represent the user (while we only want to represent the machine), but also that, being in the classical Acct choreography, it is initiated by the RADIUS client. In the case of RCM, the stable identifier may be shared with the AP/authenticator, but may also be obtained by the RADIUS server directly. In that last case, there needs to be a mechanism for the authenticator to learn from the server (auth or acct) the stable identity. We found that using Acct-Multi-Session-Id for that purpose would require too much re-engineering, and that it was healthier to define a new clean attribute instead.

All the best,

Jerome 

On 11/17/21, 5:41 AM, "[email-masked]" <[email-masked]> wrote:

    Hi,

    Regards,

    Lionel

    Orange Restricted

---

From: Alan DeKok <[email-masked]>
Date: Wed, 17 Nov 2021 10:15:23 -0500

On Nov 17, 2021, at 9:43 AM, Jerome Henry (jerhenry) <[email-masked]> wrote
> On the Acct-Multi-Session-Id,

  Acct-Multi-Session-Id is generated by the NAS, not by the device being authenticated.  While the NAS can *often* tell that one device is using multiple sessions, it can't always make that decision.

  For the NAS to send a unique device identifier which is stable, the device has to give that information to the NAS.  Generally when that happens, the device is authenticating to the network.  At that point, you might as well bypass the NAS entirely, and just dump the stable identifier into EAP.

  A related question is: do you want the NAS to *know* that the device is the same across multiple sessions?  I could see some situations (airports, coffee shops) where you don't want that information shared. But if you're doing roaming, you do want to share that information with the authentication server.

  As such, I think it's best to have a solution where the stable identifier isn't shared with the NAS.

  Alan DeKok.

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Thu, 18 Nov 2021 02:21:24 +0000

Hi Ben (and Bernard et al),

As Jerome's pointed out, both are addressing the MAC address randomization but MADINAS' charter looks to be focused on providing an assessment of the implications but not proposing any protocol updates/enhancements to what this draft is addressing.

Best, Nancy

On 11/16/21, 3:01 PM, "Benjamin Kaduk" <[email-masked]> wrote:

    Hi Nancy,

    Thanks,

    Ben

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Thu, 18 Nov 2021 02:24:06 +0000

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, "[email-masked]" <[email-masked]> wrote:

    Hi,

    Regards,

    Lionel

    Orange Restricted

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Thu, 18 Nov 2021 02:34:09 +0000

Hi Alan,
Many thanks for the thorough review and the extended thread on the draft....rather than going thru each of your feedback I can summarize by stating that we'll work to address them in a new revision. 

I do need to refer back to the 802.11 updates that are putting RCM to practice as I think one of the proposals I saw was to have the client signal the SMI but I can't recall whether it went inside an encrypted channel by which the AP would be able to see, if that is the case,  that is something we need to improve upon in that forum too.

Best, Nancy

On 11/8/21, 6:08 AM, "Alan DeKok" <[email-masked]> wrote:

    Section 2:

    Section 2.1:

    2.1.1.  General Use Cases

       ...

      ... If the

    2.1.2.  Special scenarios

        ... It is only

    2.1.3.  Failure Handling

       In that case, the RADIUS

       ...

    Summary:

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 17 Nov 2021 19:25:36 -0800

On Nov 17, 2021, at 05:34, Jerome Henry (jerhenry) <jerhenry=[email-masked]> wrote:
> This changed behavior causes the failure of multiple assumptions that have been made over the past 3 decades on the idea that one client = 1 MAC. In the case we address in this draft, we look into bringing back stability in the exchanges between an authenticator (AP/Wireless LAN controller) and RADIUS, when one side or the other gets a stable identifier (I fully agree that the context is not clear in the draft, we'll expand it).

[BA] The idea that one client = 1 MAC (or one client = 1 IP address) became suspect once multi-homing became common and even more so once virtualization took off. 

As noted in RFC 8016, multiple approaches have been tried to “bring back stability”. One approach is to attempt to make it appear as if the address has not changed (e.g. mobile IP).  

However, another approach is to provide “stability” by making the upper layer protocol agnostic to the IP address change.  If properly executed, this approach can make it more difficult for an observer on the wire to link the multiple addresses.

Examples of this approach include TLS 1.3 and protocols built on it (such as EAP TLS 1.3).  The TURN protocol initially made an assumption that a relay allocation was linked to the IP address.  Once the disadvantages became clear, TURN mobility (RFC 8016) was developed.