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

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

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" <[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.