Cisco Systems, Inc.

jerhenry@cisco.com

Cisco Systems, Inc.

ncamwing@cisco.com

General RADEXT Working Group Internet-Draft This document describes the means by which a Stable MAC address identifier can be signaled to a Authentication Authorization and Accounting (AAA) server.

In many cases where a client establishes communication over a wireless network, an observer (as defined in ) 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 device tracking and fingerprinting more difficult. An account of these efforts can be found in } draft-ietf-madinas-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 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 provide an identity independent from the RCM. For this purpose, this document specifies a Stable Machine Identifier attribute.

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 provide 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, but not the machine (that is then identified with a MAC address that may change). There are cases where the client may provide a machine identity to the RADIUS server during the authentication phase, and that the RADIUS server interprets as stable, but may not provide a stable machine identifier directly to the NAS. In some cases, the NAS cannot see the stable machine identity provided to the RADIUS server (for example because it is provided within a tunnel). In other cases, the client may provide a machine identifier to the RADIUS server during the authentication phase that the RADIUS server interprets as stable, and may also provide 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 provided 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 provided 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. This section further describes these use cases.

In this scenario, the client initially attaches to 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 information 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 cannot validate the machine identity, as no stable machine identifier is available at this point. 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.

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 via the following process. 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 access-request includes the NAS-IP-address or the NAS-Identifier, the Calling-Station-ID, the State attribute and the SMI. 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. The 48-bit value of all zeros is special, and indicates that the client is requesting a SMI. The RADIUS server supporting the SMI attribute considers the authentication as already validated and SHOULD returns an Access-Accept message containing the SMI attribute. At this point, the RADIUS records the SMI value for that client if it was in the Access-Request message and associates it with the client entry mathing the Calling-Station-ID specified in the Access-Request. If the NAS request had the SMI AVP set to the special all-zero value 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 special all-zero 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 on the other hand. The communication to the RADIUS server takes the form of the Access-Request, Access-Accept exchange described above. 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. The RCM MAC address MUST NOT change when the client use session resumption for EAP. A change at that time would indidate resumption data exchanged with a different client, and thus would be interpreted as a security breach. A client changing its MAC address MUST NOT use any cached session resumption information, and MUST start a new authentication, unless it has first been identified as a single 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.

The infrastructure can opt to represent to other infrastructure systems (including RADIUS) the client directly as the RCM (case 1), the stable identifier provided 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-Station-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. The SMI is expected to be stable, and thus to remain the same as the client changes its MAC address. However, it may happen that the client may decide to provide a new SMI during an active session. It may also happen that the infrastructure decides to change the SMI for a given client. It is only when a new stable machine identifier is shared 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 following the format described in the previous section, with the SMI AVP and its value set to the special all-zero value. 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 following the format describd in the previous section and the SMI attribute with value set to the special all-zero value. 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 as described in the previous section, with the SMI value set. The process then continues as in 2.1.1.

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 the special all-zero value even in that case. The RADIUS server not supporting the SMI is unable to process the request and SHOULD respond with an Access-Reject message. 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.

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

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-Station-ID with the SMI AVP as specified in 2.1.1, but with a payload set to the special all-zero value. As the RADIUS server uniquely identifies the machine, the RADIUS SHOULD interpret the special all-zero 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 formatetd as described in 2.1.1, that includes the SMI AVP and value. It should be clear that in cases where the client uses its real MAC address (locally-significant bit set to 0), the SMI may contain the client Calling-ID value (machine MAC address), or another identifier determined by the RADIUS server and which value is implementation-specific. In cases where the RADIUS Access-Accept message included a valid (non-zero) 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 provide 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 as described in section 2.1.1 with the SMI AVP, set to the special all-zero value. The RADIUS server has identified the client machine and SHOULD respond with an Access-Accept message, as described in section 2.1.1, 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.

In some cases, the RADIUS server supports the SMI AVP, receives the Access-Request message with the SMI value set to the special all-zero 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 the special all-zero value. The NAS records in that case that no SMI is available on the RADIUS server for this client.

As in 2.1, RADIUS servers that do not support SMI SHOULD return an Access-Reject message. 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.

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

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 formatted as described in section 2.2.1, 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 Calling-Station-ID value. 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 formated as described in 2.1.1, 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 message formated as described in 2.1.1, with the SMI AVP, which value is the one determined by the RADIUS server. The NAS records 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.

As in 2.1, RADIUS servers that do not support SMI SHOULD return an Access-Reject message. 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 the special all-zero value. 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 as described in section 2.1.1. 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, formatted as described in 2.1.1, with the SMI value set. The process then continues as in 2.3.1.

As in 2.1, RADIUS servers that do not support SMI SHOULD return an Access-Reject message. 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.

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

Type: This field is identical to the Type field of the Attribute format defined in 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 Section 5. Extended-Type The Extended type field is one octet, and follows the definition of 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. Implementations might choose to store the SMI as a 48 bit-value, to match the length of a MAC-address. However, it is RECOMMENDED to use a longer value for better atomicity, for example 256 bits.

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

Diameter needs to define an identical attribute with the same Type value. The SMI should be available as part of the NASREQ application .

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. As such, the SMI should not be either of these values, or derived from these values using a simple and reversible algorithm. 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. This risk is common to RADIUS packets and thus also applies to SMI exchanges. 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, and as specified in RFC 5080, the NAS SHOULD include a Message-Authenticator(80) attribute within Access-Request packets containing a SMI attribute.

This document requests a new RADIUS Extension Attribute to be defined as: ~~~~ Value: TBD Description: Stable Machine Identifier Data Type: string Reference: this document ~~~~~

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document offers guidance for developing privacy considerations for inclusion in protocol specifications. It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices. It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content. This document describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server. [STANDARDS-TRACK] This document describes the Diameter protocol application used for Authentication, Authorization, and Accounting (AAA) services in the Network Access Server (NAS) environment. When combined with the Diameter Base protocol, Transport Profile, and Extensible Authentication Protocol specifications, this application specification satisfies typical network access services requirements.Initial deployments of the Diameter protocol are expected to include legacy systems. Therefore, this application has been carefully designed to ease the burden of protocol conversion between RADIUS and Diameter. This is achieved by including the RADIUS attribute space to eliminate the need to perform many attribute translations.The interactions between Diameter applications and RADIUS specified in this document are to be applied to all Diameter applications. In this sense, this document extends the Base Diameter protocol. [STANDARDS-TRACK] The Remote Authentication Dial-In User Service (RADIUS) protocol is nearing exhaustion of its current 8-bit Attribute Type space. In addition, experience shows a growing need for complex grouping, along with attributes that can carry more than 253 octets of data. This document defines changes to RADIUS that address all of the above problems. CISCO Universidad Carlos III de Madrid Sky UK Group, Sky Labs Internet privacy has become a major concern over the past few years. Users are becoming more aware that their online activity leaves a vast digital footprint, that communications are not always properly secured, and that their location and actions can be easily tracked. One of the main factors for the location tracking issue is the wide use of long-lasting identifiers, such as MAC addresses. There have been several initiatives at the IETF and the IEEE 802 standards committees to overcome some of these privacy issues. This document provides an overview of these activities, with the intention to inform the technical community about them, and help coordinate between present and future standardization activities. RTFM, Inc. Fastly Cloudflare Apple, Inc. This document defines a simple mechanism for encrypting the Server Name Indication for TLS 1.3. Cisco Systems, Inc. Cisco Systems, Inc. Broadcom TLS proxies are widely deployed by organizations to enable security features and apply enterprise policies. This document defines a TLS proxy and discusses a wide range of security requirements to guide TLS proxy implementations.