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

[Bernard Aboba <[e-mail]>]

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 <[e-mail]> wrote:
> 
> On Nov 7, 2021, at 10:21 PM, Nancy Cam-Winget (ncamwing) <ncamwing=[e-mail]> wrote:
>> 
>> 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.
> 
>  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 "[e-mail]", it would send SMI 1234.  When authenticating as "[e-mail]", 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.
> 
> 
> _______________________________________________
> radext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/radext