idnits 2.17.1 draft-henry-radext-stable-mac-identifier-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** There is 1 instance of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (11 October 2021) is 928 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'NAS' is mentioned on line 97, but not defined == Unused Reference: 'RFC2119' is defined on line 535, but no explicit reference was found in the text == Unused Reference: 'RFC4005' is defined on line 545, but no explicit reference was found in the text == Unused Reference: 'ESNI' is defined on line 563, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4005 (Obsoleted by RFC 7155) ** Downref: Normative reference to an Informational RFC: RFC 6973 == Outdated reference: A later version (-18) exists of draft-ietf-tls-esni-05 Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RADEXT Working Group J. Henry 3 Internet-Draft N. Cam-Winget 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: 14 April 2022 11 October 2021 7 RADIUS attributes for Randomized and Changing MAC addresses 8 draft-henry-radext-stable-mac-identifier-00 10 Abstract 12 This document describes the means by which a Stable MAC address 13 identifier can be signaled to a Authentication Authorization and 14 Accounting (AAA) server. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on 14 April 2022. 33 Copyright Notice 35 Copyright (c) 2021 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 40 license-info) in effect on the date of publication of this document. 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. Code Components 43 extracted from this document must include Simplified BSD License text 44 as described in Section 4.e of the Trust Legal Provisions and are 45 provided without warranty as described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2.1. Stable Machine Identifier expressed to the Wireless 52 Infrastructure . . . . . . . . . . . . . . . . . . . . . 4 53 2.1.1. General Use Cases . . . . . . . . . . . . . . . . . . 4 54 2.1.2. Special scenarios . . . . . . . . . . . . . . . . . . 6 55 2.1.3. Failure Handling . . . . . . . . . . . . . . . . . . 7 56 2.2. Stable RADIUS machine identifier . . . . . . . . . . . . 7 57 2.2.1. General Use cases . . . . . . . . . . . . . . . . . . 7 58 2.2.2. Special scenarios . . . . . . . . . . . . . . . . . . 9 59 2.2.3. Failure Handling . . . . . . . . . . . . . . . . . . 9 60 2.3. Stable NAS and stable RADIUS machine identifiers . . . . 9 61 2.3.1. General cases . . . . . . . . . . . . . . . . . . . . 9 62 2.3.2. Special scenarios . . . . . . . . . . . . . . . . . . 10 63 2.3.3. Failure Handling . . . . . . . . . . . . . . . . . . 10 64 3. Stable-Machine-Identifier . . . . . . . . . . . . . . . . . . 11 65 4. Attribute table . . . . . . . . . . . . . . . . . . . . . . . 11 66 5. Security & Privacy Considerations . . . . . . . . . . . . . . 12 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 7.1. Normative References . . . . . . . . . . . . . . . . . . 12 70 7.2. Informative References . . . . . . . . . . . . . . . . . 13 71 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 74 1. Introduction 76 In many cases where a client establishes communication over a 77 wireless network, an observer (as defined in [RFC6973]) might monitor 78 the client MAC address and the associated traffic. Although the 79 traffic payload itself may be protected (e.g. encrypted in some way), 80 the outer header is commonly not obfuscated. When the client is a 81 personal device (as defined in IEEE 802E), observing the client 82 traffic may allow an attacker to characterize, from the traffic, the 83 associated user activity. For this reason, many vendors of personal 84 devices have started operating under a Randomized and Changing MAC 85 address (RCM) scheme, where the visible and external MAC address 86 changes over time, so as to make fingerprinting more difficult. An 87 account of these efforts can be found in [ZUNIGA] draft-zuniga-mac- 88 address-randomization. 90 Such RCM scheme does not necessarily mean that the client intends to 91 obfuscate the machine identifier from all infrastructure devices. In 92 many cases, the intent is to hide the MAC address from external 93 observers. For example, a wireless infrastructure may use a stable 94 identifier for the client to provide service continuity within a 95 RADIUS accounting session, between the Access Point (AP) or the 96 Wireless LAN controller (WLC), acting as a Network Access Server 97 [NAS]) and the RADIUS server; with the stable identifier being 98 independent from the RCM. In this scenario, the NAS is the means for 99 the client to access network services, and the client may expect or 100 need service continuity. Continuity might include for example 101 obtaining the same IP address from the DHCP server, the continued 102 access to cached resources or the persistence of established exchange 103 pathways. In many of these cases, the provider of the service needs 104 to be informed that a new RCM matches a previously connected object 105 that should continue to obtain the same service, independently of the 106 changed MAC address. When this happens, it is useful for the 107 continuity of network services that the wireless infrastructure, 108 acting as the NAS, exchanges with the RADIUS server about the client 109 capability to express an identity independent from the RCM. For this 110 purpose, this document specifies a Stable Machine Identifier 111 attribute. 113 2. Operations 115 The attributes in this document are intended to be applicable across 116 a wide variety of network access scenarios in which RADIUS is 117 involved: * In some cases, the client may express a machine identity 118 to the NAS, after the authentication has completed and the client has 119 established a trusted and secure connection to the AP, that the NAS 120 interprets as stable. The client may then have not provided a stable 121 machine identifier (SMI) to the RADIUS server, for example because 122 the 802.1X/EAP process authenticated the user. 124 * There are cases where the client may express a machine identity to 125 the RADIUS server during the authentication phase, and that the 126 RADIUS server interprets as stable, but may not express a stable 127 machine identifier to the NAS. 129 * In other cases, the client may express a machine identifier to the 130 RADIUS server during the authentication phase that the RADIUS 131 server interprets as stable, and may also express a machine 132 identifier to the NAS after the establishment of a trusted and 133 secure connection to the AP, that the NAS interprets as stable. 134 The machine identifier expressed to the NAS and the RADIUS server 135 may not be the same. 137 It should be noted that cases where both the NAS and the RADIUS 138 server are unable to determine a stable machine identifier for the 139 client are not considered in this document. Additionally, the 140 machine identifier expressed to the NAS or the RADIUS server may not 141 be the SMI attribute in this document. However, the machine 142 identifier is interpreted as stable by the receiving side. 144 This section further describes these use cases. 146 2.1. Stable Machine Identifier expressed to the Wireless Infrastructure 148 In this scenario, the client initially joins the network in a 149 constrained state and proceeds through the 802.1X/EAP authentication 150 phase. The client MAC address is likely locally administered (second 151 bit of first octet set), although this condition is not necessary for 152 support of the SMI attribute. This characteristic is visible to the 153 NAS (in the client source address) and possibly to the RADIUS server 154 (in the Calling-Station-ID). The RADIUS validates the user identity 155 (but not a stable machine identity). After the RADIUS server returns 156 an Access-Accept, keying material is built on the client and on the 157 NAS. 159 Once authentication is completed and a protected link has been 160 established between the client machine and the access network 161 infrastructure (acting as NAS), the client machine exchanges with the 162 infrastructure a stable identifier. In one scenario, the client 163 provides a stable identifier to the AP/WLC. In another scenario, the 164 client requests a stable identifier from the AP/WLC. 166 In cases where the client generates the stable identifier, the NAS 167 records the identifier and uses it as SMI. Some implementations may 168 choose to let the NAS generate a SMI in all cases, and simply map the 169 NAS SMI to the stable identifier returned by the client. 171 2.1.1. General Use Cases 173 In all cases, the RADIUS server received during the 802.1X/EAP phase 174 the client RCM as the Calling-Station-Id value. When the client 175 rotates its MAC address, the RADIUS server receives the new MAC 176 Address as the Calling-Station-Id, and has no mechanism to know that 177 the same client machine is initiating a new session with a new MAC 178 address. This can cause database inflation on the RADIUS server, 179 keeping cached a set of policies for a client that may never come 180 back (as the client is already back with a different MAC address), or 181 causing possible confusion when RCM collision happens. If the 182 wireless infrastructure (NAS) receives a stable machine identifier 183 information from the client, after authentication with the client 184 first MAC address, then the NAS SHOULD share this identifier with the 185 RADIUS server. 187 Thus, after the NAS has received a stable identifier representation 188 from the client machine, the NAS SHOULD send a new access-request 189 message to the RADIUS server. The SMI attribute SHOULD be added with 190 the value determined by the NAS from the identifier sent by the 191 client machine. The Calling-Station-ID is the current RCM MAC 192 address. If the STA is requesting the SMI, the SMI payload SHOULD 193 set to Null. 195 The RADIUS server supporting the SMI attribute considers the 196 authentication as already validated and SHOULD returns an Access- 197 Accept message. At this point, the RADIUS records the SMI value for 198 that client if it was in the Access-Request message. 200 If the NAS request had the SMI AVP set to Null and the RADIUS server 201 did not uniquely identify the client machine, then the RADIUS server 202 SHOULD return an Access-Accept message with the SMI AVP set to the 203 Null value. The NAS then generates a local SMI for the client, and 204 sends it to the client machine over a protected frame on one hand, 205 and to the RADIUS server as above on the other hand. 207 Later, the client rotates its MAC address. If neither the wireless 208 infrastructure or the RADIUS server is forewarned about the change, 209 then a new session is started and the process above repeats. 210 Alternatively, several implementations allow the client machine to 211 forewarn the wireless infrastructure about the upcoming RCM change, 212 and for the AP to know in advance the value of the next MAC address 213 for that client. In that case, the infrastructure recognizes the 214 same machine in the new MAC address. However, the MAC address has 215 changed from the RADIUS viewpoint (new Calling-Station-ID) and most 216 implementations will require a new authentication. As the client 217 initiates a new authentication request to the RADIUS server, the 218 Calling-Station-ID is the new MAC address, and the RADIUS server sees 219 the client as a new machine. 221 Thus as above, at the end of the re-authentication phase, the NAS 222 SHOULD send to the RADIUS server a new Access-Request message 223 mentioning both the new Calling-Station-ID and the SMI. The RADIUS 224 server records the unicity of the machine across both MAC addresses. 225 This information can be used to flush the older entry, provide 226 continuation of policies (posture) or other purposes. 228 If the SMI was included in an Access-Request packet, the NAS MUST 229 ensure that the SMI appears in subsequent Accounting-Request (Start, 230 Interim and Stop) for the same client. 232 Later and at any time, the source of the SMI (the client or the NAS) 233 may update the SMI value. At that time, the NAS SHOULD send to the 234 RADIUS server the updated SMI as per above. In all these cases, the 235 SMI is a new attribute to the session identity that the RADIUS server 236 is tracking. 238 2.1.2. Special scenarios 240 The infrastructure can opt to represent to other infrastructure 241 systems (including RADIUS) the client directly as the RCM (case 1), 242 the stable identifier expressed by the client (case 2), or another 243 stable identifier generated by the infrastructure (case 3). In case 244 1, the RADIUS server receives the RCM as the Calling-Id and the 245 provisions from 2.1.1 apply directly. In cases 2 and 3, when the 246 client changes its MAC address and the infrastructure immediately 247 recognizes the new MAC address as representing the same machine as 248 before, no client MAC address change occurs from the perspective of 249 the other infrastructure systems. In this context, RCM management is 250 only occurring within the infrastructure system acting as the NAS, 251 and no new SMI exchange is needed with the RADIUS server. It is only 252 when a new stable machine identifier is expressed between the NAS the 253 other infrastructure elements that a new SMI exchange is needed 254 between the NAS and the RADIUS server. 256 In some cases, the AP and the client establish a secure link, but the 257 client does not immediately exchange with the infrastructure on a 258 unique identifier. In that case, the NAS is initially unable to 259 establish a unique identifier for the client machine, but does not 260 know if the RADIUS server may have such value. Thus, after a secure 261 link has been established with the client, the NAS SHOULD send an 262 Access-Request message to the RADIUS server with the SMI AVP and its 263 value set to Null. The RADIUS server supporting the SMI attribute 264 but that has not established a unique identifier for the client 265 machine SHOULD respond with an Access-Accept message and the SMI 266 attribute with value set to Null. Just as above, the NAS then 267 records that the RADIUS server does not have a stable identifier for 268 the client. Later, the client machine and the NAS exchange on a 269 stable identifier. After this exchange completes, the NAS SHOULD 270 send a new Access-Request to the RADIUS server with the SMI value 271 set. The process then continues as in 2.1.1. 273 2.1.3. Failure Handling 275 Clients not supporting stable identifiers exchanges with the wireless 276 infrastructure will neither provide a stable identifier to the AP/WLC 277 nor request one. As the NAS is unable to determine if the client has 278 exchanged a stable identifier with the RADIUS server, the NAS SHOULD 279 initiate an Access-Request with the SMI value set to Null even in 280 that case. 282 The RADIUS server not supporting the SMI is unable to process the 283 request and SHOULD respond with an Access-Reject, a NACK, or SHOULD 284 NOT respond. The NAS SHOULD then consider that the RADIUS server is 285 unable to exchange SMI values for that client, and should stop 286 sending Access-Requests with SMI values pertaining to that client to 287 that RADIUS server. In this configuration, it is likely that a solid 288 implementation will record this non-support, and stop sending SMIs 289 for later clients as well. 291 Additionally, the RADIUS server may detect an anomaly in the SMI 292 (format error, duplication, suspicion of impersonation or other 293 malicious detection). The RADIUS server may then return to the NAS a 294 warning in the form of a VSA, thus causing the NAS to reject or 295 contain the offender. 297 2.2. Stable RADIUS machine identifier 299 Some methods use RADIUS to authenticate the client machine itself, 300 irrespective of the user authentication. In that case, the RADIUS 301 server receives a stable identifier for the machine, even when the 302 MAC address and the associated Calling Station-Id are changing. 304 In this case, the client initially joins the network in a constrained 305 state and proceeds through the 802.1X/EAP authentication phase. The 306 client MAC address is likely locally administered. During the 307 authentication phase, the RADIUS server validates the machine 308 identity, or validates the user identity with an identifier also 309 unique for the particular machine. 311 2.2.1. General Use cases 313 After the NAS and the client machine have established a secure 314 connection, no stable identifier exchange occurs between the client 315 and the NAS. Thus the NAS SHOULD send to the RADIUS server an 316 Access-Request for the Calling-ID with the SMI AVP, but with a 317 payload set to the Null value. 319 As the RADIUS server uniquely identifies the machine, the RADIUS 320 SHOULD interpret the Null value as 1. the NAS supports the SMI AVP, 321 2. the NAS does not have an SMI yet for this client and 3. the NAS 322 requests the SMI for the client, if available. 324 The RADIUS server having established a unique identifier for the 325 client machine SHOULD respond with an Access-Accept response that 326 includes the SMI AVP and value. It should be clear that in cases 327 where the STA uses its real MAC address (locally-significant bit set 328 to 0), the SMI may contain the STA Calling-ID value (STA MAC 329 address), or another identifier determined by the RADIUS server and 330 which value is implementation-specific. 332 In cases where the RADIUS returned a valid SMI value, the NAS records 333 this identifier as a stable value for the client machine. 335 Later, client MAC rotation occurs and the client does not express a 336 stable identifier to the NAS during that phase. The NAS thus 337 considers the new MAC address as a new client and initiates 802.1X 338 authentication. 340 At the end of the authentication, the RADIUS server and the NAS 341 operate as above: the NAS SHOULD send an Access-Request message with 342 the SMI AVP, set to Null. The RADIUS server has identified the 343 client machine and SHOULD respond with an Access-Accept containing 344 the SMI AVP and value. 346 The NAS uses this value to recognize that the new MAC is the same 347 client as the previous MAC. the NAS can then use this awareness to 348 facilitate network operations (e.g. flush previous MAC address cached 349 keys, ensure IP address continuity [DHCP proxy], inform upstream 350 devices [gratuitous ARPs] or others). 352 If the SMI was included in an Access-Request packet, the NAS MUST 353 ensure that the SMI appears in subsequent Accounting-Request (Start, 354 Interim and Stop) for the same client. 356 Later and at any time, the source of the SMI (the client or the NAS) 357 may update the SMI value. At that time, the NAS SHOULD send to the 358 RADIUS server the updated SMI as per above. In all these cases, the 359 SMI is a new attribute to the session identity that the RADIUS server 360 is tracking. 362 2.2.2. Special scenarios 364 In some cases, the RADIUS server supports the SMI AVP, receives the 365 Access-Request message with the SMI value set to Null from the NAS, 366 but the RADIUS server did not uniquely authenticate the machine (e.g. 367 user authentication). The RADIUS server SHOULD then return an 368 Access-Accept message, with the SMI AVP, which payload value is set 369 to Null. The NAS records in that case that no SMI is available on 370 the RADIUS server for this client. 372 2.2.3. Failure Handling 374 As in 2.1, RADIUS servers that do not support SMI SHOULD return an 375 Access-Reject, a NACK, or SHOULD NOT respond. RADIUS servers that do 376 not receive an Access-Request message with the SMI value from the NAS 377 SHOULD NOT send an unsolicited SMI attribute and value to the NAS. 379 2.3. Stable NAS and stable RADIUS machine identifiers 381 In this scenario, both the NAS and the RADIUS server are able to 382 establish a stable identity for the client, from their respective 383 exchanges with the client. The client first joins the network in a 384 constrained state and proceeds through the 802.1X/EAP authentication 385 phase. The client MAC address is likely locally administered. As in 386 2.2, the server RADIUS uniquely identifies the machine. 387 Additionally, once a protected link has been established between the 388 client and the AP/WLC, as in 2.1, the client requests from the NAS a 389 stable identifier or provides to the NAS a stable identifier. This 390 identifier may be different from that established by the RADIUS 391 server. 393 2.3.1. General cases 395 After keying material is exchanged between the NAS and the client 396 machine, scenario 2.1 occurs. The NAS SHOULD send an Access-Request 397 message to the RADIUS server with the SMI AVP. The AVP value is the 398 client identifier determined by the NAS. The RADIUS server compares 399 the value to its own SMI value for that client. Several 400 possibilities arise: * Some RADIUS implementations may decide to 401 replace the RADIUS SMI with the SMI forwarded by the NAS. In that 402 case, the RADIUS server SHOULD return to the NAS an Access-Accept, 403 optionally with the SMI AVP, which value is the one sent by the NAS. 404 The NAS records the Access-Accept to signify that the SMI was 405 successfully recorded by the supporting RADIUS server. * Some 406 implementations may decide to replace the NAS SMI with the SMI 407 determined by the RADIUS server. In that case, the RADIUS server 408 SHOULD return to the NAS an Access-Accept, with the SMI AVP, which 409 value is the one determined by the RADIUS server. The NAS records 410 the Access-Accept and the SMI returned by the RADIUS server. Some 411 NAS implementations may decide to conserve both values, some others 412 may decide to replace the NAS SMI with the SMI returned by the RADIUS 413 server. 415 If the SMI was included in an Access-Request packet, the NAS MUST 416 ensure that the SMI appears in subsequent Accounting-Request (Start, 417 Interim and Stop) for the same client. 419 Later and at any time, the source of the SMI (the client or the NAS) 420 may update the SMI value. At that time, the NAS SHOULD send to the 421 RADIUS server the updated SMI as per above. In all these cases, the 422 SMI is a new attribute to the session identity that the RADIUS server 423 is tracking. 425 2.3.2. Special scenarios 427 As in 2.1, RADIUS servers that do not support SMI SHOULD return an 428 Access-Reject, a NACK, or SHOULD NOT respond. In some cases, the AP 429 and the client establish a secure link, but the client does not 430 immediately exchange with the infrastructure on a unique identifier. 431 In that case, the NAS is initially unable to establish a unique 432 identifier for the client machine, but does not know if the RADIUS 433 server may have such value. Thus, after a secure link has been 434 established with the client, the NAS SHOULD send an Access-Request 435 message to the RADIUS server with the SMI AVP and its value set to 436 Null. The RADIUS server supporting the SMI attribute that has 437 established a unique identifier for the client machine SHOULD respond 438 with an Access-Accept message and the SMI attribute and its value. 439 Just as in 2.2, the NAS then records the RADIUS server SMI value for 440 the client. 442 Later, the client machine and the NAS exchange on a stable 443 identifier. After this exchange completes, the NAS SHOULD send a new 444 Access-Request to the RADIUS server with the SMI value set. The 445 process then continues as in 2.3.1. 447 2.3.3. Failure Handling 449 As in 2.1, RADIUS servers that do not support SMI SHOULD return an 450 Access-Reject, a NACK, or SHOULD NOT respond. RADIUS servers that do 451 not receive an Access-Request message with the SMI value from the NAS 452 SHOULD NOT send an unsolicited SMI attribute and value to the NAS. 454 3. Stable-Machine-Identifier 456 The Stable-Machine-Identifier attribute conveys the SMI. A summary 457 of the RADIUS SMI attribute is shown below. The fields are 458 transmitted from left to right. The assignment rules follow RFC 6929 459 section 10.3 461 0 1 2 3 462 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 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | Type | Length | Extended-Type | Value … 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 Type: 469 This field is identical to the Type field of the Attribute format 470 defined in [RFC2865] Section 5. The code is 241. 472 Length 474 The Length field is one octet and indicates the length of this 475 Attribute, including the Type, Length, and "Value" fields. This 476 field is identical to the Type field of the Attribute format defined 477 in [RFC2865] Section 5. 479 Extended-Type The Extended type field is one octet, and follows the 480 definition of [RFC6929] section 2.1. The code is 12. 482 Value The Value represents the Stable Machine Identifier. The format 483 and content of the value is implementation-specific. Most 484 implementations might choose to store the SMI as a 48 bit-value. 486 4. Attribute table 488 The following table provides a guide to which attribute(s) may be 489 found in which kinds of packets, and in what quantity. 491 Request Accept Reject Challenge Accounting # Attribute 493 Request 495 0-1 0-1 0 0 0-1 241.12 Stable Machine Identifier 497 5. Security & Privacy Considerations 499 It is strongly recommended that the SMI format used is such that 500 neither the machine globally unique MAC address nor the machine user 501 identity are revealed. Furthermore, where a reference is used to the 502 machine globally unique MAC address or to the machine user identity, 503 it is recommended that the binding lifetime of that reference be kept 504 as short as possible. 506 The RADIUS entities (RADIUS proxies and clients) outside the home 507 network MUST NOT modify the SMI or insert a SMI in an Access-Accept. 508 However, there is no way to detect or prevent this. 510 Attempting theft of service, a man-in-the-middle may try to insert, 511 modify, or remove the SMI in the Access-Accept packets and Accounting 512 packets. However, RADIUS Access-Accept and Accounting packets 513 already provide integrity protection. 515 If the NAS includes SMI in an Access-Request packet, a man-in-the- 516 middle may remove it. This will cause the issues that the SMI was 517 designed to solve. To prevent such an attack, the NAS SHOULD include 518 a Message-Authenticator(80) attribute within Access-Request packets 519 containing a SMI attribute. 521 6. IANA Considerations 523 This document requests a new RADIUS Extension Attribute to be defined 524 as: 526 Value: TBD 527 Description: Stable Machine Identifier 528 Data Type: string 529 Reference: this document 531 7. References 533 7.1. Normative References 535 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 536 Requirement Levels", BCP 14, RFC 2119, 537 DOI 10.17487/RFC2119, March 1997, 538 . 540 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 541 "Remote Authentication Dial In User Service (RADIUS)", 542 RFC 2865, DOI 10.17487/RFC2865, June 2000, 543 . 545 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 546 "Diameter Network Access Server Application", RFC 4005, 547 DOI 10.17487/RFC4005, August 2005, 548 . 550 [RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User 551 Service (RADIUS) Protocol Extensions", RFC 6929, 552 DOI 10.17487/RFC6929, April 2013, 553 . 555 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 556 Morris, J., Hansen, M., and R. Smith, "Privacy 557 Considerations for Internet Protocols", RFC 6973, 558 DOI 10.17487/RFC6973, July 2013, 559 . 561 7.2. Informative References 563 [ESNI] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, 564 "Encrypted Server Name Indication for TLS 1.3", Work in 565 Progress, Internet-Draft, draft-ietf-tls-esni-05, 4 566 November 2019, . 569 [SEC_IMPACT] 570 Durumeric, Z., Ma, Z., Springall, D., Barnes, R., 571 Sullivan, N., Bursztein, E., Bailey, M., Halderman, J.A., 572 and V. Paxson, "The Security Impact of HTTPS 573 Interception", 26 February 2017, 574 . 576 [TLS_PROXY] 577 Wang, E., Ossipov, A., and R. DuToit, "TLS Proxy Best 578 Practice", Work in Progress, Internet-Draft, draft-wang- 579 tls-proxy-best-practice-01, 4 March 2020, 580 . 583 [ZUNIGA] Zuniga, J. C., Bernardos, C. J., and A. Andersdotter, "MAC 584 address randomization", Work in Progress, Internet-Draft, 585 draft-zuniga-mac-address-randomization-01, 12 July 2021, 586 . 589 Acknowledgments 591 Authors' Addresses 592 Jerome Henry 593 Cisco Systems, Inc. 595 Email: jerhenry@cisco.com 597 Nancy Cam-Winget 598 Cisco Systems, Inc. 600 Email: ncamwing@cisco.com