[Search] [txt|html|xml|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
RADEXT Working Group                                            J. Henry
Internet-Draft                                             N. Cam-Winget
Intended status: Standards Track                     Cisco Systems, Inc.
Expires: 14 April 2022                                   11 October 2021


      RADIUS attributes for Randomized and Changing MAC addresses
              draft-henry-radext-stable-mac-identifier-00

Abstract

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

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 14 April 2022.

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Simplified BSD License text
   as described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Simplified BSD License.






Henry & Cam-Winget        Expires 14 April 2022                 [Page 1]


Internet-Draft               RADIUS SMI TLV                 October 2021


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Operations  . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Stable Machine Identifier expressed to the Wireless
           Infrastructure  . . . . . . . . . . . . . . . . . . . . .   4
       2.1.1.  General Use Cases . . . . . . . . . . . . . . . . . .   4
       2.1.2.  Special scenarios . . . . . . . . . . . . . . . . . .   6
       2.1.3.  Failure Handling  . . . . . . . . . . . . . . . . . .   7
     2.2.  Stable RADIUS machine identifier  . . . . . . . . . . . .   7
       2.2.1.  General Use cases . . . . . . . . . . . . . . . . . .   7
       2.2.2.  Special scenarios . . . . . . . . . . . . . . . . . .   9
       2.2.3.  Failure Handling  . . . . . . . . . . . . . . . . . .   9
     2.3.  Stable NAS and stable RADIUS machine identifiers  . . . .   9
       2.3.1.  General cases . . . . . . . . . . . . . . . . . . . .   9
       2.3.2.  Special scenarios . . . . . . . . . . . . . . . . . .  10
       2.3.3.  Failure Handling  . . . . . . . . . . . . . . . . . .  10
   3.  Stable-Machine-Identifier . . . . . . . . . . . . . . . . . .  11
   4.  Attribute table . . . . . . . . . . . . . . . . . . . . . . .  11
   5.  Security & Privacy Considerations . . . . . . . . . . . . . .  12
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  13
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   In many cases where a client establishes communication over a
   wireless network, an observer (as defined in [RFC6973]) might monitor
   the client MAC address and the associated traffic.  Although the
   traffic payload itself may be protected (e.g. encrypted in some way),
   the outer header is commonly not obfuscated.  When the client is a
   personal device (as defined in IEEE 802E), observing the client
   traffic may allow an attacker to characterize, from the traffic, the
   associated user activity.  For this reason, many vendors of personal
   devices have started operating under a Randomized and Changing MAC
   address (RCM) scheme, where the visible and external MAC address
   changes over time, so as to make fingerprinting more difficult.  An
   account of these efforts can be found in [ZUNIGA] draft-zuniga-mac-
   address-randomization.

   Such RCM scheme does not necessarily mean that the client intends to
   obfuscate the machine identifier from all infrastructure devices.  In
   many cases, the intent is to hide the MAC address from external
   observers.  For example, a wireless infrastructure may use a stable
   identifier for the client to provide service continuity within a



Henry & Cam-Winget        Expires 14 April 2022                 [Page 2]


Internet-Draft               RADIUS SMI TLV                 October 2021


   RADIUS accounting session, between the Access Point (AP) or the
   Wireless LAN controller (WLC), acting as a Network Access Server
   [NAS]) and the RADIUS server; with the stable identifier being
   independent from the RCM.  In this scenario, the NAS is the means for
   the client to access network services, and the client may expect or
   need service continuity.  Continuity might include for example
   obtaining the same IP address from the DHCP server, the continued
   access to cached resources or the persistence of established exchange
   pathways.  In many of these cases, the provider of the service needs
   to be informed that a new RCM matches a previously connected object
   that should continue to obtain the same service, independently of the
   changed MAC address.  When this happens, it is useful for the
   continuity of network services that the wireless infrastructure,
   acting as the NAS, exchanges with the RADIUS server about the client
   capability to express an identity independent from the RCM.  For this
   purpose, this document specifies a Stable Machine Identifier
   attribute.

2.  Operations

   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, the client may express a machine identity
   to the NAS, after the authentication has completed and the client has
   established a trusted and secure connection to the AP, that the NAS
   interprets as stable.  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.

   *  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.

   *  In other cases, the client may express a machine identifier to the
      RADIUS server during the authentication phase that the RADIUS
      server interprets as stable, and may also express a machine
      identifier to the NAS after the establishment of a trusted and
      secure connection to the AP, that the NAS interprets as stable.
      The machine identifier expressed to the NAS and the RADIUS server
      may not be the same.

   It should be noted that cases where both the NAS and the RADIUS
   server are unable to determine a stable machine identifier for the
   client are not considered in this document.  Additionally, the
   machine identifier expressed to the NAS or the RADIUS server may not
   be the SMI attribute in this document.  However, the machine
   identifier is interpreted as stable by the receiving side.



Henry & Cam-Winget        Expires 14 April 2022                 [Page 3]


Internet-Draft               RADIUS SMI TLV                 October 2021


   This section further describes these use cases.

2.1.  Stable Machine Identifier expressed to the Wireless Infrastructure

   In this scenario, the client initially joins the network in a
   constrained state and proceeds through the 802.1X/EAP authentication
   phase.  The client MAC address is likely locally administered (second
   bit of first octet set), although this condition is not necessary for
   support of the SMI attribute.  This characteristic is visible to the
   NAS (in the client source address) and possibly to the RADIUS server
   (in the Calling-Station-ID).  The RADIUS validates the user identity
   (but not a stable machine identity).  After the RADIUS server returns
   an Access-Accept, keying material is built on the client and on the
   NAS.

   Once authentication is completed and a protected link has been
   established between the client machine and the access network
   infrastructure (acting as NAS), the client machine exchanges with the
   infrastructure a stable identifier.  In one scenario, the client
   provides a stable identifier to the AP/WLC.  In another scenario, the
   client requests a stable identifier from the AP/WLC.

   In cases where the client generates the stable identifier, the NAS
   records the identifier and uses it as SMI.  Some implementations may
   choose to let the NAS generate a SMI in all cases, and simply map the
   NAS SMI to the stable identifier returned by the client.

2.1.1.  General Use Cases

   In all cases, the RADIUS server received during the 802.1X/EAP phase
   the client RCM as the Calling-Station-Id value.  When the client
   rotates its MAC address, the RADIUS server receives the new MAC
   Address as the Calling-Station-Id, and has no mechanism to know that
   the same client machine is initiating a new session with a new MAC
   address.  This can cause database inflation on the RADIUS server,
   keeping cached a set of policies for a client that may never come
   back (as the client is already back with a different MAC address), or
   causing possible confusion when RCM collision happens.  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.









Henry & Cam-Winget        Expires 14 April 2022                 [Page 4]


Internet-Draft               RADIUS SMI TLV                 October 2021


   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.  The SMI attribute SHOULD be added with
   the value determined by the NAS from the identifier sent by the
   client machine.  The Calling-Station-ID is the current RCM MAC
   address.  If the STA is requesting the SMI, the SMI payload SHOULD
   set to Null.

   The RADIUS server supporting the SMI attribute considers the
   authentication as already validated and SHOULD returns an Access-
   Accept message.  At this point, the RADIUS records the SMI value for
   that client if it was in the Access-Request message.

   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.

   Later, the client rotates its MAC address.  If neither the wireless
   infrastructure or the RADIUS server is forewarned about the change,
   then a new session is started and the process above repeats.
   Alternatively, several implementations allow the client machine to
   forewarn the wireless infrastructure about the upcoming RCM change,
   and for the AP to know in advance the value of the next MAC address
   for that client.  In that case, the infrastructure recognizes the
   same machine in the new MAC address.  However, the MAC address has
   changed from the RADIUS viewpoint (new Calling-Station-ID) and most
   implementations will require a new authentication.  As the client
   initiates a new authentication request to the RADIUS server, the
   Calling-Station-ID is the new MAC address, and the RADIUS server sees
   the client as a new machine.

   Thus as above, at the end of the re-authentication phase, the NAS
   SHOULD send to the RADIUS server a new Access-Request message
   mentioning both the new Calling-Station-ID and the SMI.  The RADIUS
   server records the unicity of the machine across both MAC addresses.
   This information can be used to flush the older entry, provide
   continuation of policies (posture) or other purposes.

   If the SMI was included in an Access-Request packet, the NAS MUST
   ensure that the SMI appears in subsequent Accounting-Request (Start,
   Interim and Stop) for the same client.







Henry & Cam-Winget        Expires 14 April 2022                 [Page 5]


Internet-Draft               RADIUS SMI TLV                 October 2021


   Later and at any time, the source of the SMI (the client or the NAS)
   may update the SMI value.  At that time, the NAS SHOULD send to the
   RADIUS server the updated SMI as per above.  In all these cases, the
   SMI is a new attribute to the session identity that the RADIUS server
   is tracking.

2.1.2.  Special scenarios

   The infrastructure can opt to represent to other infrastructure
   systems (including RADIUS) the client directly as the RCM (case 1),
   the stable identifier expressed by the client (case 2), or another
   stable identifier generated by the infrastructure (case 3).  In case
   1, the RADIUS server receives the RCM as the Calling-Id and the
   provisions from 2.1.1 apply directly.  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.  In this context, RCM management is
   only occurring within the infrastructure system acting as the NAS,
   and no new SMI exchange is needed with the RADIUS server.  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.

   In some cases, the AP and the client establish a secure link, but the
   client does not immediately exchange with the infrastructure on a
   unique identifier.  In that case, the NAS is initially unable to
   establish a unique identifier for the client machine, but does not
   know if the RADIUS server may have such value.  Thus, after a secure
   link has been established with the client, the NAS SHOULD send an
   Access-Request message to the RADIUS server with the SMI AVP and its
   value set to Null.  The RADIUS server supporting the SMI attribute
   but that has not established a unique identifier for the client
   machine SHOULD respond with an Access-Accept message and the SMI
   attribute with value set to Null.  Just as above, the NAS then
   records that the RADIUS server does not have a stable identifier for
   the client.  Later, the client machine and the NAS exchange on a
   stable identifier.  After this exchange completes, the NAS SHOULD
   send a new Access-Request to the RADIUS server with the SMI value
   set.  The process then continues as in 2.1.1.











Henry & Cam-Winget        Expires 14 April 2022                 [Page 6]


Internet-Draft               RADIUS SMI TLV                 October 2021


2.1.3.  Failure Handling

   Clients not supporting stable identifiers exchanges with the wireless
   infrastructure will neither provide a stable identifier to the AP/WLC
   nor request one.  As the NAS is unable to determine if the client has
   exchanged a stable identifier with the RADIUS server, the NAS SHOULD
   initiate an Access-Request with the SMI value set to Null even in
   that case.

   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.  The NAS SHOULD then consider that the RADIUS server is
   unable to exchange SMI values for that client, and should stop
   sending Access-Requests with SMI values pertaining to that client to
   that RADIUS server.  In this configuration, it is likely that a solid
   implementation will record this non-support, and stop sending SMIs
   for later clients as well.

   Additionally, the RADIUS server may detect an anomaly in the SMI
   (format error, duplication, suspicion of impersonation or other
   malicious detection).  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.

2.2.  Stable RADIUS machine identifier

   Some methods use RADIUS to authenticate the client machine itself,
   irrespective of the user authentication.  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.

   In this case, the client initially joins the network in a constrained
   state and proceeds through the 802.1X/EAP authentication phase.  The
   client MAC address is likely locally administered.  During the
   authentication phase, the RADIUS server validates the machine
   identity, or validates the user identity with an identifier also
   unique for the particular machine.

2.2.1.  General Use cases

   After the NAS and the client machine have established a secure
   connection, no stable identifier exchange occurs between the client
   and the NAS.  Thus the NAS SHOULD send to the RADIUS server an
   Access-Request for the Calling-ID with the SMI AVP, but with a
   payload set to the Null value.






Henry & Cam-Winget        Expires 14 April 2022                 [Page 7]


Internet-Draft               RADIUS SMI TLV                 October 2021


   As the RADIUS server uniquely identifies the machine, the RADIUS
   SHOULD interpret the Null value as 1. the NAS supports the SMI AVP,
   2. the NAS does not have an SMI yet for this client and 3. the NAS
   requests the SMI for the client, if available.

   The RADIUS server having established a unique identifier for the
   client machine SHOULD respond with an Access-Accept response that
   includes the SMI AVP and value.  It should be clear that in cases
   where the STA uses its real MAC address (locally-significant bit set
   to 0), the SMI may contain the STA Calling-ID value (STA MAC
   address), or another identifier determined by the RADIUS server and
   which value is implementation-specific.

   In cases where the RADIUS returned a valid SMI value, the NAS records
   this identifier as a stable value for the client machine.

   Later, client MAC rotation occurs and the client does not express a
   stable identifier to the NAS during that phase.  The NAS thus
   considers the new MAC address as a new client and initiates 802.1X
   authentication.

   At the end of the authentication, the RADIUS server and the NAS
   operate as above: the NAS SHOULD send an Access-Request message with
   the SMI AVP, set to Null.  The RADIUS server has identified the
   client machine and SHOULD respond with an Access-Accept containing
   the SMI AVP and value.

   The NAS uses this value to recognize that the new MAC is the same
   client as the previous MAC. the NAS can then use this awareness to
   facilitate network operations (e.g. flush previous MAC address cached
   keys, ensure IP address continuity [DHCP proxy], inform upstream
   devices [gratuitous ARPs] or others).

   If the SMI was included in an Access-Request packet, the NAS MUST
   ensure that the SMI appears in subsequent Accounting-Request (Start,
   Interim and Stop) for the same client.

   Later and at any time, the source of the SMI (the client or the NAS)
   may update the SMI value.  At that time, the NAS SHOULD send to the
   RADIUS server the updated SMI as per above.  In all these cases, the
   SMI is a new attribute to the session identity that the RADIUS server
   is tracking.









Henry & Cam-Winget        Expires 14 April 2022                 [Page 8]


Internet-Draft               RADIUS SMI TLV                 October 2021


2.2.2.  Special scenarios

   In some cases, the RADIUS server supports the SMI AVP, receives the
   Access-Request message with the SMI value set to Null from the NAS,
   but the RADIUS server did not uniquely authenticate the machine (e.g.
   user authentication).  The RADIUS server SHOULD then return an
   Access-Accept message, with the SMI AVP, which payload value is set
   to Null.  The NAS records in that case that no SMI is available on
   the RADIUS server for this client.

2.2.3.  Failure Handling

   As in 2.1, RADIUS servers that do not support SMI SHOULD return an
   Access-Reject, a NACK, or SHOULD NOT respond.  RADIUS servers that do
   not receive an Access-Request message with the SMI value from the NAS
   SHOULD NOT send an unsolicited SMI attribute and value to the NAS.

2.3.  Stable NAS and stable RADIUS machine identifiers

   In this scenario, both the NAS and the RADIUS server are able to
   establish a stable identity for the client, from their respective
   exchanges with the client.  The client first joins the network in a
   constrained state and proceeds through the 802.1X/EAP authentication
   phase.  The client MAC address is likely locally administered.  As in
   2.2, the server RADIUS uniquely identifies the machine.
   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
   identifier may be different from that established by the RADIUS
   server.

2.3.1.  General cases

   After keying material is exchanged between the NAS and the client
   machine, scenario 2.1 occurs.  The NAS SHOULD send an Access-Request
   message to the RADIUS server with the SMI AVP.  The AVP value is the
   client identifier determined by the NAS.  The RADIUS server compares
   the value to its own SMI value for that client.  Several
   possibilities arise: * Some RADIUS implementations may decide to
   replace the RADIUS SMI with the SMI forwarded by the NAS.  In that
   case, the RADIUS server SHOULD return to the NAS an Access-Accept,
   optionally with the SMI AVP, which value is the one sent by the NAS.
   The NAS records the Access-Accept to signify that the SMI was
   successfully recorded by the supporting RADIUS server. * Some
   implementations may decide to replace the NAS SMI with the SMI
   determined by the RADIUS server.  In that case, the RADIUS server
   SHOULD return to the NAS an Access-Accept, with the SMI AVP, which
   value is the one determined by the RADIUS server.  The NAS records



Henry & Cam-Winget        Expires 14 April 2022                 [Page 9]


Internet-Draft               RADIUS SMI TLV                 October 2021


   the Access-Accept and the SMI returned by the RADIUS server.  Some
   NAS implementations may decide to conserve both values, some others
   may decide to replace the NAS SMI with the SMI returned by the RADIUS
   server.

   If the SMI was included in an Access-Request packet, the NAS MUST
   ensure that the SMI appears in subsequent Accounting-Request (Start,
   Interim and Stop) for the same client.

   Later and at any time, the source of the SMI (the client or the NAS)
   may update the SMI value.  At that time, the NAS SHOULD send to the
   RADIUS server the updated SMI as per above.  In all these cases, the
   SMI is a new attribute to the session identity that the RADIUS server
   is tracking.

2.3.2.  Special scenarios

   As in 2.1, RADIUS servers that do not support SMI SHOULD return an
   Access-Reject, a NACK, or SHOULD NOT respond.  In some cases, the AP
   and the client establish a secure link, but the client does not
   immediately exchange with the infrastructure on a unique identifier.
   In that case, the NAS is initially unable to establish a unique
   identifier for the client machine, but does not know if the RADIUS
   server may have such value.  Thus, after a secure link has been
   established with the client, the NAS SHOULD send an Access-Request
   message to the RADIUS server with the SMI AVP and its value set to
   Null.  The RADIUS server supporting the SMI attribute that has
   established a unique identifier for the client machine SHOULD respond
   with an Access-Accept message and the SMI attribute and its value.
   Just as in 2.2, the NAS then records the RADIUS server SMI value for
   the client.

   Later, the client machine and the NAS exchange on a stable
   identifier.  After this exchange completes, the NAS SHOULD send a new
   Access-Request to the RADIUS server with the SMI value set.  The
   process then continues as in 2.3.1.

2.3.3.  Failure Handling

   As in 2.1, RADIUS servers that do not support SMI SHOULD return an
   Access-Reject, a NACK, or SHOULD NOT respond.  RADIUS servers that do
   not receive an Access-Request message with the SMI value from the NAS
   SHOULD NOT send an unsolicited SMI attribute and value to the NAS.








Henry & Cam-Winget        Expires 14 April 2022                [Page 10]


Internet-Draft               RADIUS SMI TLV                 October 2021


3.  Stable-Machine-Identifier

   The Stable-Machine-Identifier attribute conveys the SMI.  A summary
   of the RADIUS SMI attribute is shown below.  The fields are
   transmitted from left to right.  The assignment rules follow RFC 6929
   section 10.3

   0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     | Extended-Type | Value …
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:

   This field is identical to the Type field of the Attribute format
   defined in [RFC2865] Section 5.  The code is 241.

   Length

   The Length field is one octet and indicates the length of this
   Attribute, including the Type, Length, and "Value" fields.  This
   field is identical to the Type field of the Attribute format defined
   in [RFC2865] Section 5.

   Extended-Type The Extended type field is one octet, and follows the
   definition of [RFC6929] section 2.1.  The code is 12.

   Value The Value represents the Stable Machine Identifier.  The format
   and content of the value is implementation-specific.  Most
   implementations might choose to store the SMI as a 48 bit-value.

4.  Attribute table

   The following table provides a guide to which attribute(s) may be
   found in which kinds of packets, and in what quantity.

   Request Accept Reject Challenge Accounting #     Attribute

                                    Request

     0-1    0-1     0        0        0-1    241.12 Stable Machine Identifier









Henry & Cam-Winget        Expires 14 April 2022                [Page 11]


Internet-Draft               RADIUS SMI TLV                 October 2021


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

   The RADIUS entities (RADIUS proxies and clients) outside the home
   network MUST NOT modify the SMI or insert a SMI in an Access-Accept.
   However, there is no way to detect or prevent this.

   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.

   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.

6.  IANA Considerations

   This document requests a new RADIUS Extension Attribute to be defined
   as:

        Value: TBD
        Description: Stable Machine Identifier
        Data Type: string
        Reference: this document

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)",
              RFC 2865, DOI 10.17487/RFC2865, June 2000,
              <https://www.rfc-editor.org/info/rfc2865>.




Henry & Cam-Winget        Expires 14 April 2022                [Page 12]


Internet-Draft               RADIUS SMI TLV                 October 2021


   [RFC4005]  Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
              "Diameter Network Access Server Application", RFC 4005,
              DOI 10.17487/RFC4005, August 2005,
              <https://www.rfc-editor.org/info/rfc4005>.

   [RFC6929]  DeKok, A. and A. Lior, "Remote Authentication Dial In User
              Service (RADIUS) Protocol Extensions", RFC 6929,
              DOI 10.17487/RFC6929, April 2013,
              <https://www.rfc-editor.org/info/rfc6929>.

   [RFC6973]  Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
              Morris, J., Hansen, M., and R. Smith, "Privacy
              Considerations for Internet Protocols", RFC 6973,
              DOI 10.17487/RFC6973, July 2013,
              <https://www.rfc-editor.org/info/rfc6973>.

7.2.  Informative References

   [ESNI]     Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood,
              "Encrypted Server Name Indication for TLS 1.3", Work in
              Progress, Internet-Draft, draft-ietf-tls-esni-05, 4
              November 2019, <https://www.ietf.org/archive/id/draft-
              ietf-tls-esni-05.txt>.

   [SEC_IMPACT]
              Durumeric, Z., Ma, Z., Springall, D., Barnes, R.,
              Sullivan, N., Bursztein, E., Bailey, M., Halderman, J.A.,
              and V. Paxson, "The Security Impact of HTTPS
              Interception", 26 February 2017,
              <https://jhalderm.com/pub/papers/interception-ndss17.pdf>.

   [TLS_PROXY]
              Wang, E., Ossipov, A., and R. DuToit, "TLS Proxy Best
              Practice", Work in Progress, Internet-Draft, draft-wang-
              tls-proxy-best-practice-01, 4 March 2020,
              <https://www.ietf.org/archive/id/draft-wang-tls-proxy-
              best-practice-01.txt>.

   [ZUNIGA]   Zuniga, J. C., Bernardos, C. J., and A. Andersdotter, "MAC
              address randomization", Work in Progress, Internet-Draft,
              draft-zuniga-mac-address-randomization-01, 12 July 2021,
              <https://www.ietf.org/archive/id/draft-zuniga-mac-address-
              randomization-01.txt>.

Acknowledgments

Authors' Addresses




Henry & Cam-Winget        Expires 14 April 2022                [Page 13]


Internet-Draft               RADIUS SMI TLV                 October 2021


   Jerome Henry
   Cisco Systems, Inc.

   Email: jerhenry@cisco.com


   Nancy Cam-Winget
   Cisco Systems, Inc.

   Email: ncamwing@cisco.com









































Henry & Cam-Winget        Expires 14 April 2022                [Page 14]