idnits 2.17.00 (12 Aug 2021) /tmp/idnits26189/draft-henry-radext-stable-mac-identifier-01.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 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 April 2022) is 33 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 98, but not defined == Unused Reference: 'RFC2119' is defined on line 563, but no explicit reference was found in the text == Unused Reference: 'ESNI' is defined on line 591, but no explicit reference was found in the text == Unused Reference: 'ZUNIGA' is defined on line 611, 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 (-14) exists of draft-ietf-tls-esni-05 Summary: 4 errors (**), 0 flaws (~~), 7 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: 13 October 2022 11 April 2022 7 RADIUS attributes for Randomized and Changing MAC addresses 8 draft-henry-radext-stable-mac-identifier-01 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 13 October 2022. 33 Copyright Notice 35 Copyright (c) 2022 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 Revised BSD License text as 44 described in Section 4.e of the Trust Legal Provisions and are 45 provided without warranty as described in the Revised BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2.1. Stable Machine Identifier provided 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 . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . 11 64 3. Stable-Machine-Identifier . . . . . . . . . . . . . . . . . . 11 65 4. Attribute table . . . . . . . . . . . . . . . . . . . . . . . 11 66 5. Diameter Consideration . . . . . . . . . . . . . . . . . . . 12 67 6. Security & Privacy Considerations . . . . . . . . . . . . . . 12 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 71 8.2. Informative References . . . . . . . . . . . . . . . . . 13 72 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 75 1. Introduction 77 In many cases where a client establishes communication over a 78 wireless network, an observer (as defined in [RFC6973]) might monitor 79 the client MAC address and the associated traffic. Although the 80 traffic payload itself may be protected (e.g. encrypted in some way), 81 the outer header is commonly not obfuscated. When the client is a 82 personal device (as defined in IEEE 802E), observing the client 83 traffic may allow an attacker to characterize, from the traffic, the 84 associated user activity. For this reason, many vendors of personal 85 devices have started operating under a Randomized and Changing MAC 86 address (RCM) scheme, where the visible and external MAC address 87 changes over time, so as to make device tracking and fingerprinting 88 more difficult. An account of these efforts can be found in 89 [ZUNIGA]} draft-ietf-madinas-mac-address-randomization. 91 Such RCM scheme does not necessarily mean that the client intends to 92 obfuscate the machine identifier from all infrastructure devices. In 93 many cases, the intent is to hide the MAC address from external 94 observers. For example, a wireless infrastructure may use a stable 95 identifier for the client to provide service continuity within a 96 RADIUS accounting session, between the Access Point (AP) or the 97 Wireless LAN controller (WLC), acting as a Network Access Server 98 [NAS]) and the RADIUS server; with the stable identifier being 99 independent from the RCM. In this scenario, the NAS is the means for 100 the client to access network services, and the client may expect or 101 need service continuity. Continuity might include for example 102 obtaining the same IP address from the DHCP server, the continued 103 access to cached resources or the persistence of established exchange 104 pathways. In many of these cases, the provider of the service needs 105 to be informed that a new RCM matches a previously connected object 106 that should continue to obtain the same service, independently of the 107 changed MAC address. When this happens, it is useful for the 108 continuity of network services that the wireless infrastructure, 109 acting as the NAS, exchanges with the RADIUS server about the client 110 capability to provide an identity independent from the RCM. For this 111 purpose, this document specifies a Stable Machine Identifier 112 attribute. 114 2. Use cases 116 The attributes in this document are intended to be applicable across 117 a wide variety of network access scenarios in which RADIUS is 118 involved: 120 * In some cases, the client may provide a machine identity to the 121 NAS, after the authentication has completed and the client has 122 established a trusted and secure connection to the AP, that the 123 NAS interprets as stable. The client may then have not provided a 124 stable machine identifier (SMI) to the RADIUS server, for example 125 because the 802.1X/EAP process authenticated the user, but not the 126 machine (that is then identified with a MAC address that may 127 change). 129 * There are cases where the client may provide a machine identity to 130 the RADIUS server during the authentication phase, and that the 131 RADIUS server interprets as stable, but may not provide a stable 132 machine identifier directly to the NAS. In some cases, the NAS 133 cannot see the stable machine identity provided to the RADIUS 134 server (for example because it is provided within a tunnel). 136 * In other cases, the client may provide a machine identifier to the 137 RADIUS server during the authentication phase that the RADIUS 138 server interprets as stable, and may also provide a machine 139 identifier to the NAS after the establishment of a trusted and 140 secure connection to the AP, that the NAS interprets as stable. 141 The machine identifier provided to the NAS and the RADIUS server 142 may not be the same. 144 It should be noted that cases where both the NAS and the RADIUS 145 server are unable to determine a stable machine identifier for the 146 client are not considered in this document. Additionally, the 147 machine identifier provided to the NAS or the RADIUS server may not 148 be the SMI attribute in this document. However, the machine 149 identifier is interpreted as stable by the receiving side. 151 This section further describes these use cases. 153 2.1. Stable Machine Identifier provided to the Wireless Infrastructure 155 In this scenario, the client initially attaches to the network in a 156 constrained state and proceeds through the 802.1X/EAP authentication 157 phase. The client MAC address is likely locally administered (second 158 bit of first octet set), although this condition is not necessary for 159 support of the SMI attribute. This information is visible to the NAS 160 (in the client source address) and possibly to the RADIUS server (in 161 the Calling-Station-ID). The RADIUS validates the user identity, but 162 cannot validate the machine identity, as no stable machine identifier 163 is available at this point. After the RADIUS server returns an 164 Access-Accept, keying material is built on the client and on the NAS. 166 Once authentication is completed and a protected link has been 167 established between the client machine and the access network 168 infrastructure (acting as NAS), the client machine exchanges with the 169 infrastructure a stable identifier. In one scenario, the client 170 provides a stable identifier to the AP/WLC. In another scenario, the 171 client requests a stable identifier from the AP/WLC. 173 In cases where the client generates the stable identifier, the NAS 174 records the identifier and uses it as SMI. Some implementations may 175 choose to let the NAS generate a SMI in all cases, and simply map the 176 NAS SMI to the stable identifier returned by the client. 178 2.1.1. General Use Cases 180 In all cases, the RADIUS server received during the 802.1X/EAP phase 181 the client RCM as the Calling-Station-Id value. When the client 182 rotates its MAC address, the RADIUS server receives the new MAC 183 Address as the Calling-Station-Id, and has no mechanism to know that 184 the same client machine is initiating a new session with a new MAC 185 address. This can cause database inflation on the RADIUS server, 186 keeping cached a set of policies for a client that may never come 187 back (as the client is already back with a different MAC address), or 188 causing possible confusion when RCM collision happens. If the 189 wireless infrastructure (NAS) receives a stable machine identifier 190 information from the client, after authentication with the client 191 first MAC address, then the NAS SHOULD share this identifier with the 192 RADIUS server via the following process. 194 After the NAS has received a stable identifier representation from 195 the client machine, the NAS SHOULD send a new access-request message 196 to the RADIUS server. The access-request includes the NAS-IP-address 197 or the NAS-Identifier, the Calling-Station-ID, the State attribute 198 and the SMI. The SMI attribute SHOULD be added with the value 199 determined by the NAS from the identifier sent by the client machine. 200 The Calling-Station-ID is the current RCM MAC address. The 48-bit 201 value of all zeros is special, and indicates that the client is 202 requesting a SMI. 204 The RADIUS server supporting the SMI attribute considers the 205 authentication as already validated and SHOULD returns an Access- 206 Accept message containing the SMI attribute. At this point, the 207 RADIUS records the SMI value for that client if it was in the Access- 208 Request message and associates it with the client entry mathing the 209 Calling-Station-ID specified in the Access-Request. 211 If the NAS request had the SMI AVP set to the special all-zero value 212 and the RADIUS server did not uniquely identify the client machine, 213 then the RADIUS server SHOULD return an Access-Accept message with 214 the SMI AVP set to the special all-zero value. The NAS then 215 generates a local SMI for the client, and sends it to the client 216 machine over a protected frame on one hand, and to the RADIUS server 217 on the other hand. The communication to the RADIUS server takes the 218 form of the Access-Request, Access-Accept exchange described above. 220 Later, the client rotates its MAC address. If neither the wireless 221 infrastructure or the RADIUS server is forewarned about the change, 222 then a new session is started and the process above repeats. 223 Alternatively, several implementations allow the client machine to 224 forewarn the wireless infrastructure about the upcoming RCM change, 225 and for the AP to know in advance the value of the next MAC address 226 for that client. In that case, the infrastructure recognizes the 227 same machine in the new MAC address. However, the MAC address has 228 changed from the RADIUS viewpoint (new Calling-Station-ID) and most 229 implementations will require a new authentication. As the client 230 initiates a new authentication request to the RADIUS server, the 231 Calling-Station-ID is the new MAC address, and the RADIUS server sees 232 the client as a new machine. 234 Thus as above, at the end of the re-authentication phase, the NAS 235 SHOULD send to the RADIUS server a new Access-Request message 236 mentioning both the new Calling-Station-ID and the SMI. The RADIUS 237 server records the unicity of the machine across both MAC addresses. 238 This information can be used to flush the older entry, provide 239 continuation of policies (posture) or other purposes. 241 If the SMI was included in an Access-Request packet, the NAS MUST 242 ensure that the SMI appears in subsequent Accounting-Request (Start, 243 Interim and Stop) for the same client. 245 The RCM MAC address MUST NOT change when the client use session 246 resumption for EAP. A change at that time would indidate resumption 247 data exchanged with a different client, and thus would be interpreted 248 as a security breach. A client changing its MAC address MUST NOT use 249 any cached session resumption information, and MUST start a new 250 authentication, unless it has first been identified as a single 251 client. 253 Later and at any time, the source of the SMI (the client or the NAS) 254 may update the SMI value. At that time, the NAS SHOULD send to the 255 RADIUS server the updated SMI as per above. In all these cases, the 256 SMI is a new attribute to the session identity that the RADIUS server 257 is tracking. 259 2.1.2. Special scenarios 261 The infrastructure can opt to represent to other infrastructure 262 systems (including RADIUS) the client directly as the RCM (case 1), 263 the stable identifier provided by the client (case 2), or another 264 stable identifier generated by the infrastructure (case 3). In case 265 1, the RADIUS server receives the RCM as the Calling-Station-Id and 266 the provisions from 2.1.1 apply directly. In cases 2 and 3, when the 267 client changes its MAC address and the infrastructure immediately 268 recognizes the new MAC address as representing the same machine as 269 before, no client MAC address change occurs from the perspective of 270 the other infrastructure systems. In this context, RCM management is 271 only occurring within the infrastructure system acting as the NAS, 272 and no new SMI exchange is needed with the RADIUS server. The SMI is 273 expected to be stable, and thus to remain the same as the client 274 changes its MAC address. However, it may happen that the client may 275 decide to provide a new SMI during an active session. It may also 276 happen that the infrastructure decides to change the SMI for a given 277 client. It is only when a new stable machine identifier is shared 278 between the NAS the other infrastructure elements that a new SMI 279 exchange is needed between the NAS and the RADIUS server. 281 In some cases, the AP and the client establish a secure link, but the 282 client does not immediately exchange with the infrastructure on a 283 unique identifier. In that case, the NAS is initially unable to 284 establish a unique identifier for the client machine, but does not 285 know if the RADIUS server may have such value. Thus, after a secure 286 link has been established with the client, the NAS SHOULD send an 287 Access-Request message to the RADIUS server following the format 288 described in the previous section, with the SMI AVP and its value set 289 to the special all-zero value. The RADIUS server supporting the SMI 290 attribute but that has not established a unique identifier for the 291 client machine SHOULD respond with an Access-Accept message following 292 the format describd in the previous section and the SMI attribute 293 with value set to the special all-zero value. Just as above, the NAS 294 then records that the RADIUS server does not have a stable identifier 295 for the client. Later, the client machine and the NAS exchange on a 296 stable identifier. After this exchange completes, the NAS SHOULD 297 send a new Access-Request to the RADIUS server as described in the 298 previous section, with the SMI value set. The process then continues 299 as in 2.1.1. 301 2.1.3. Failure Handling 303 Clients not supporting stable identifiers exchanges with the wireless 304 infrastructure will neither provide a stable identifier to the AP/WLC 305 nor request one. As the NAS is unable to determine if the client has 306 exchanged a stable identifier with the RADIUS server, the NAS SHOULD 307 initiate an Access-Request with the SMI value set to the special all- 308 zero value even in that case. 310 The RADIUS server not supporting the SMI is unable to process the 311 request and SHOULD respond with an Access-Reject message. The NAS 312 SHOULD then consider that the RADIUS server is unable to exchange SMI 313 values for that client, and SHOULD stop sending Access-Requests with 314 SMI values pertaining to that client to that RADIUS server. In this 315 configuration, it is likely that a solid implementation will record 316 this non-support, and stop sending SMIs for later clients as well. 318 2.2. Stable RADIUS machine identifier 320 Some methods use RADIUS to authenticate the client machine itself, 321 irrespective of the user authentication. In that case, the RADIUS 322 server receives a stable identifier for the machine, even when the 323 MAC address and the associated Calling Station-Id are changing. 325 In this case, the client initially attaches to the network in a 326 constrained state and proceeds through the 802.1X/EAP authentication 327 phase. The client MAC address is likely locally administered. 328 During the authentication phase, the RADIUS server validates the 329 machine identity, or validates the user identity with an identifier 330 also unique for the particular machine. 332 2.2.1. General Use cases 334 After the NAS and the client machine have established a secure 335 connection, no stable identifier exchange occurs between the client 336 and the NAS. Thus the NAS SHOULD send to the RADIUS server an 337 Access-Request for the Calling-Station-ID with the SMI AVP as 338 specified in 2.1.1, but with a payload set to the special all-zero 339 value. 341 As the RADIUS server uniquely identifies the machine, the RADIUS 342 SHOULD interpret the special all-zero value as 1. the NAS supports 343 the SMI AVP, 2. the NAS does not have an SMI yet for this client and 344 3. the NAS requests the SMI for the client, if available. 346 The RADIUS server having established a unique identifier for the 347 client machine SHOULD respond with an Access-Accept response 348 formatetd as described in 2.1.1, that includes the SMI AVP and value. 349 It should be clear that in cases where the client uses its real MAC 350 address (locally-significant bit set to 0), the SMI may contain the 351 client Calling-ID value (machine MAC address), or another identifier 352 determined by the RADIUS server and which value is implementation- 353 specific. 355 In cases where the RADIUS Access-Accept message included a valid 356 (non-zero) SMI value, the NAS records this identifier as a stable 357 value for the client machine. 359 Later, client MAC rotation occurs and the client does not provide a 360 stable identifier to the NAS during that phase. The NAS thus 361 considers the new MAC address as a new client and initiates 802.1X 362 authentication. 364 At the end of the authentication, the RADIUS server and the NAS 365 operate as above: the NAS SHOULD send an Access-Request message as 366 described in section 2.1.1 with the SMI AVP, set to the special all- 367 zero value. The RADIUS server has identified the client machine and 368 SHOULD respond with an Access-Accept message, as described in section 369 2.1.1, containing the SMI AVP and value. 371 The NAS uses this value to recognize that the new MAC is the same 372 client as the previous MAC. the NAS can then use this awareness to 373 facilitate network operations (e.g. flush previous MAC address cached 374 keys, ensure IP address continuity [DHCP proxy], inform upstream 375 devices [gratuitous ARPs] or others). 377 If the SMI was included in an Access-Request packet, the NAS MUST 378 ensure that the SMI appears in subsequent Accounting-Request (Start, 379 Interim and Stop) for the same client. 381 Later and at any time, the source of the SMI (the client or the NAS) 382 may update the SMI value. At that time, the NAS SHOULD send to the 383 RADIUS server the updated SMI as per above. In all these cases, the 384 SMI is a new attribute to the session identity that the RADIUS server 385 is tracking. 387 2.2.2. Special scenarios 389 In some cases, the RADIUS server supports the SMI AVP, receives the 390 Access-Request message with the SMI value set to the special all-zero 391 from the NAS, but the RADIUS server did not uniquely authenticate the 392 machine (e.g. user authentication). The RADIUS server SHOULD then 393 return an Access-Accept message, with the SMI AVP, which payload 394 value is set to the special all-zero value. The NAS records in that 395 case that no SMI is available on the RADIUS server for this client. 397 2.2.3. Failure Handling 399 As in 2.1, RADIUS servers that do not support SMI SHOULD return an 400 Access-Reject message. RADIUS servers that do not receive an Access- 401 Request message with the SMI value from the NAS SHOULD NOT send an 402 unsolicited SMI attribute and value to the NAS. 404 2.3. Stable NAS and stable RADIUS machine identifiers 406 In this scenario, both the NAS and the RADIUS server are able to 407 establish a stable identity for the client, from their respective 408 exchanges with the client. The client first attaches to the network 409 in a constrained state and proceeds through the 802.1X/EAP 410 authentication phase. The client MAC address is likely locally 411 administered. As in 2.2, the server RADIUS uniquely identifies the 412 machine. Additionally, once a protected link has been established 413 between the client and the AP/WLC, as in 2.1, the client requests 414 from the NAS a stable identifier or provides to the NAS a stable 415 identifier. This identifier may be different from that established 416 by the RADIUS server. 418 2.3.1. General cases 420 After keying material is exchanged between the NAS and the client 421 machine, scenario 2.1 occurs. The NAS SHOULD send an Access-Request 422 message to the RADIUS server formatted as described in section 2.2.1, 423 with the SMI AVP. The AVP value is the client identifier determined 424 by the NAS. The RADIUS server compares the value to its own SMI 425 value for that Calling-Station-ID value. Several possibilities 426 arise: * Some RADIUS implementations may decide to replace the RADIUS 427 SMI with the SMI forwarded by the NAS. In that case, the RADIUS 428 server SHOULD return to the NAS an Access-Accept formated as 429 described in 2.1.1, optionally with the SMI AVP, which value is the 430 one sent by the NAS. The NAS records the Access-Accept to signify 431 that the SMI was successfully recorded by the supporting RADIUS 432 server. * Some implementations may decide to replace the NAS SMI with 433 the SMI determined by the RADIUS server. In that case, the RADIUS 434 server SHOULD return to the NAS an Access-Accept message formated as 435 described in 2.1.1, with the SMI AVP, which value is the one 436 determined by the RADIUS server. The NAS records the Access-Accept 437 and the SMI returned by the RADIUS server. Some NAS implementations 438 may decide to conserve both values, some others may decide to replace 439 the NAS SMI with the SMI returned by the RADIUS server. 441 If the SMI was included in an Access-Request packet, the NAS MUST 442 ensure that the SMI appears in subsequent Accounting-Request (Start, 443 Interim and Stop) for the same client. 445 Later and at any time, the source of the SMI (the client or the NAS) 446 may update the SMI value. At that time, the NAS SHOULD send to the 447 RADIUS server the updated SMI as per above. In all these cases, the 448 SMI is a new attribute to the session identity that the RADIUS server 449 is tracking. 451 2.3.2. Special scenarios 453 As in 2.1, RADIUS servers that do not support SMI SHOULD return an 454 Access-Reject message. In some cases, the AP and the client 455 establish a secure link, but the client does not immediately exchange 456 with the infrastructure on a unique identifier. In that case, the 457 NAS is initially unable to establish a unique identifier for the 458 client machine, but does not know if the RADIUS server may have such 459 value. Thus, after a secure link has been established with the 460 client, the NAS SHOULD send an Access-Request message to the RADIUS 461 server with the SMI AVP and its value set to the special all-zero 462 value. The RADIUS server supporting the SMI attribute that has 463 established a unique identifier for the client machine SHOULD respond 464 with an Access-Accept message and the SMI attribute and its value as 465 described in section 2.1.1. Just as in 2.2, the NAS then records the 466 RADIUS server SMI value for the client. 468 Later, the client machine and the NAS exchange on a stable 469 identifier. After this exchange completes, the NAS SHOULD send a new 470 Access-Request to the RADIUS server, formatted as described in 2.1.1, 471 with the SMI value set. The process then continues as in 2.3.1. 473 2.3.3. Failure Handling 475 As in 2.1, RADIUS servers that do not support SMI SHOULD return an 476 Access-Reject message. RADIUS servers that do not receive an Access- 477 Request message with the SMI value from the NAS SHOULD NOT send an 478 unsolicited SMI attribute and value to the NAS. 480 3. Stable-Machine-Identifier 482 The Stable-Machine-Identifier attribute conveys the SMI. A summary 483 of the RADIUS SMI attribute is shown below. The fields are 484 transmitted from left to right. The assignment rules follow RFC 6929 485 section 10.3 487 0 1 2 3 488 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 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | Type | Length | Extended-Type | Value … 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 Type: 495 This field is identical to the Type field of the Attribute format 496 defined in [RFC2865] Section 5. The code is 241. 498 Length 500 The Length field is one octet and indicates the length of this 501 Attribute, including the Type, Length, and "Value" fields. This 502 field is identical to the Type field of the Attribute format defined 503 in [RFC2865] Section 5. 505 Extended-Type The Extended type field is one octet, and follows the 506 definition of [RFC6929] section 2.1. The code is 12. 508 Value The Value represents the Stable Machine Identifier. The format 509 and content of the value is implementation-specific. Implementations 510 might choose to store the SMI as a 48 bit-value, to match the length 511 of a MAC-address. However, it is RECOMMENDED to use a longer value 512 for better atomicity, for example 256 bits. 514 4. Attribute table 516 The following table provides a guide to which attribute(s) may be 517 found in which kinds of packets, and in what quantity. 519 Request Accept Reject Challenge Accounting # Attribute 520 Request 521 0-1 0-1 0 0 0-1 241.12 Stable Machine Identifier 523 5. Diameter Consideration 525 Diameter needs to define an identical attribute with the same Type 526 value. The SMI should be available as part of the NASREQ application 527 [RFC4005]. 529 6. Security & Privacy Considerations 531 It is strongly recommended that the SMI format used is such that 532 neither the machine globally unique MAC address nor the machine user 533 identity are revealed. As such, the SMI should not be either of 534 these values, or derived from these values using a simple and 535 reversible algorithm. 537 The RADIUS entities (RADIUS proxies and clients) outside the home 538 network MUST NOT modify the SMI or insert a SMI in an Access-Accept. 539 However, there is no way to detect or prevent this. 541 Attempting theft of service, a man-in-the-middle may try to insert, 542 modify, or remove the SMI in the Access-Accept packets and Accounting 543 packets. This risk is common to RADIUS packets and thus also applies 544 to SMI exchanges. However, RADIUS Access-Accept and Accounting 545 packets already provide integrity protection. 547 If the NAS includes SMI in an Access-Request packet, a man-in-the- 548 middle may remove it. This will cause the issues that the SMI was 549 designed to solve. To prevent such an attack, and as specified in 550 RFC 5080, the NAS SHOULD include a Message-Authenticator(80) 551 attribute within Access-Request packets containing a SMI attribute. 553 7. IANA Considerations 555 This document requests a new RADIUS Extension Attribute to be defined 556 as: ~~~~ Value: TBD Description: Stable Machine Identifier Data Type: 557 string Reference: this document ~~~~~ 559 8. References 561 8.1. Normative References 563 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 564 Requirement Levels", BCP 14, RFC 2119, 565 DOI 10.17487/RFC2119, March 1997, 566 . 568 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 569 "Remote Authentication Dial In User Service (RADIUS)", 570 RFC 2865, DOI 10.17487/RFC2865, June 2000, 571 . 573 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 574 "Diameter Network Access Server Application", RFC 4005, 575 DOI 10.17487/RFC4005, August 2005, 576 . 578 [RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User 579 Service (RADIUS) Protocol Extensions", RFC 6929, 580 DOI 10.17487/RFC6929, April 2013, 581 . 583 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 584 Morris, J., Hansen, M., and R. Smith, "Privacy 585 Considerations for Internet Protocols", RFC 6973, 586 DOI 10.17487/RFC6973, July 2013, 587 . 589 8.2. Informative References 591 [ESNI] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, 592 "Encrypted Server Name Indication for TLS 1.3", Work in 593 Progress, Internet-Draft, draft-ietf-tls-esni-05, 4 594 November 2019, . 597 [SEC_IMPACT] 598 Durumeric, Z., Ma, Z., Springall, D., Barnes, R., 599 Sullivan, N., Bursztein, E., Bailey, M., Halderman, J.A., 600 and V. Paxson, "The Security Impact of HTTPS 601 Interception", 26 February 2017, 602 . 604 [TLS_PROXY] 605 Wang, E., Ossipov, A., and R. DuToit, "TLS Proxy Best 606 Practice", Work in Progress, Internet-Draft, draft-wang- 607 tls-proxy-best-practice-01, 4 March 2020, 608 . 611 [ZUNIGA] Zuniga, J. C., Bernardos, C. J., and A. Andersdotter, "MAC 612 address randomization", Work in Progress, Internet-Draft, 613 draft-ietf-madinas-mac-address-randomization-01, 7 March 614 2022, . 617 Acknowledgments 619 Authors' Addresses 621 Jerome Henry 622 Cisco Systems, Inc. 623 Email: jerhenry@cisco.com 625 Nancy Cam-Winget 626 Cisco Systems, Inc. 627 Email: ncamwing@cisco.com