RADIUS attributes for Randomized and Changing MAC addressesCisco Systems, Inc.jerhenry@cisco.comCisco Systems, Inc.ncamwing@cisco.com
General
RADEXT Working GroupInternet-DraftThis 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.3Type:This field is identical to the Type field of the Attribute format defined in Section 5. The code is 241.LengthThe 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
~~~~~Key words for use in RFCs to Indicate Requirement LevelsIn 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.Privacy Considerations for Internet ProtocolsThis 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.Remote Authentication Dial In User Service (RADIUS)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]Diameter Network Access Server ApplicationThis 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]Remote Authentication Dial In User Service (RADIUS) Protocol ExtensionsThe 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.MAC address randomizationCISCOUniversidad Carlos III de MadridSky 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.
Encrypted Server Name Indication for TLS 1.3RTFM, Inc.FastlyCloudflareApple, Inc. This document defines a simple mechanism for encrypting the Server
Name Indication for TLS 1.3.
TLS Proxy Best PracticeCisco 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.
The Security Impact of HTTPS Interception