RFC 8559

Dynamic Authorization Proxying in the Remote Authentication Dial-In User Service (RADIUS) Protocol

📅 published April 2019, from ietf

Dynamic Authorization Proxying in the Remote Authentication Dial-In User Service (RADIUS) Protocol ✨

  • RFC: 8559 🎀
  • Authors: A. DeKok (FreeRADIUS) and J. Korhonen 💖
  • Stream: Internet Engineering Task Force (IETF) 🌸
  • Category: Standards Track 👑
  • Date: April 2019 🦋
  • ISSN: 2070-1721 🧚
  • Updates: RFC 5176 and RFC 5580 🫶

Abstract

okay so RFC 5176 defines Change-of-Authorization (CoA) and Disconnect Message (DM) behavior for RADIUS 💅 It also hints that proxying these messages is possible, but it never explains how to actually do it 😭 This spec fixes that gap for networks that use realm-based proxying as defined in RFC 7542 ✨ It also updates RFC 5580 so the Operator-Name attribute can show up in CoA-Request and Disconnect-Request packets 🔥

Status of This Memo

this is an Internet Standards Track document 🌈

it's a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community 🫶 it got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 👑 if you want more info on Internet Standards, check out Section 2 of RFC 7841 📚

for the current status, any errata, and how to give feedback, go to https://www.rfc-editor.org/info/rfc8559 🦋

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

this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication 📜 please actually read these, because they spell out your rights and restrictions for this document 🙈 code components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License ⚠️

Table of Contents

   1. Introduction ....................................................3
      1.1. Terminology ................................................4
      1.2. Requirements Language ......................................5
   2. Problem Statement ...............................................5
      2.1. Typical RADIUS Proxying ....................................5
      2.2. CoA Processing .............................................6
      2.3. Failure of CoA Proxying ....................................6
   3. How to Perform CoA Proxying .....................................7
      3.1. Changes to Access-Request and Accounting-Request Packets ...8
      3.2. Proxying of CoA-Request and Disconnect-Request Packets .....9
      3.3. Reception of CoA-Request and Disconnect-Request Packets ...10
      3.4. Operator-NAS-Identifier ...................................11
   4. Requirements ...................................................14
      4.1. Requirements on Home Servers ..............................14
      4.2. Requirements on Visited Networks ..........................14
      4.3. Requirements on Proxies ...................................14
           4.3.1. Security Requirements on Proxies ...................15
           4.3.2. Filtering Requirements on Proxies ..................16
   5. Functionality ..................................................17
      5.1. User Login ................................................17
      5.2. CoA Proxying ..............................................17
   6. Security Considerations ........................................18
      6.1. RADIUS Security and Proxies ...............................18
      6.2. Security of the Operator-NAS-Identifier Attribute .........19
   7. IANA Considerations ............................................20
   8. References .....................................................20
      8.1. Normative References ......................................20
      8.2. Informative References ....................................21
   Authors' Addresses ................................................21

1. Introduction ✨

okay bestie, so [RFC5176] defines Change-of-Authorization (CoA) and Disconnect Message (DM) behavior for RADIUS 💖 Section 3.1 of [RFC5176] suggests that proxying these messages is possible, but it doesn't give any guidance on how to do it 😭 this omission means that in practice, proxying of CoA packets is impossible 💀

we partially fix that here 🎀 we explain how proxying these packets can work by using an attribute that already exists, Operator-Name (Section 4.1 of [RFC5580]) ✨ then we show how proxies can use this attribute to route packets "backwards" through a RADIUS proxy chain, from a home network to a visited network 🔥 and we introduce a brand new attribute, Operator-NAS-Identifier 🦋 that lets packets get routed from the RADIUS server at the visited network to the Network Access Server (NAS) 👑

this fix is limited to realm-based proxying as defined in [RFC7542] 🌸 other kinds of proxying exist, but we're not talking about them here 🙈 the recommendations in this document only apply to systems that implement CoA proxying, and then only to the ones doing realm-based CoA proxying 💅 this spec neither requires nor suggests changes to any implementation or deployment of any other RADIUS systems 🫶

we also update the behavior in [RFC5580] so that the Operator-Name attribute can be used in CoA-Request and Disconnect-Request packets, as described further in this document 🌈

this is a Standards Track document because it updates the behavior described in [RFC5580], and [RFC5580] is also a Standards Track document 📜 this document leans heavily on [RFC5176] and also updates some of its behaviors 💜 but [RFC5176] is an Informational document, and the applicability statements in Section 1.1 of [RFC5176] don't apply to this document, so this document doesn't change the status of [RFC5176] 🧚

last but not least, we wrap up with a discussion of the security implications of this design and show that they don't decrease the security of the network 🔒✨

1.1. Terminology

this document uses these terms a lot, so here they are 🎀

CoA

Change of authorization, e.g., CoA-Request, CoA-ACK, or CoA-NAK, as defined in [RFC5176]. [RFC5176] also defines Disconnect-Request, Disconnect-ACK, and Disconnect-NAK. To keep things simple, wherever this document says "CoA," it means a generic "CoA-Request or Disconnect-Request" packet. We use "CoA-Request" or "Disconnect-Request" when we mean one specific packet type. 💅

Network Access Identifier (NAI)

The user identity the client submits during network access authentication. See [RFC7542]. The NAI's job is to identify the user and help route the authentication request 🫶 heads up: the NAI might not be the same as the user's email address or the user identity submitted in an application-layer authentication 🙈

Network Access Server (NAS)

The device clients connect to in order to get onto the network. In Point-to-Point Tunneling Protocol (PPTP) terminology, this is called the PPTP Access Concentrator (PAC), and in Layer 2 Tunneling Protocol (L2TP) terminology, it's called the L2TP Access Concentrator (LAC). In IEEE 802.11, it's called an Access Point 📡

Home Network

The network that holds the authentication credentials for a user 🏠

Visited Network

Any network other than the home network, where the user tries to get network access. The visited network usually has a relationship with the home network, possibly through one or more intermediary proxies 🌍

1.2. Requirements Language

here's the deal with the requirement words 🎀 the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in BCP 14 [RFC2119] [RFC8174], but only when they show up in all capitals, exactly like this 💖 if they're lowercase, they're just regular words 😌

2. Problem Statement 🔥

this section explains how RADIUS proxying works, how CoA packets work, and why the CoA proxying discussed in [RFC5176] isn't enough to build a working system 💀

2.1. Typical RADIUS Proxying

when a RADIUS server proxies an Access-Request packet, it usually does so based on the contents of the User-Name attribute, which holds an NAI [RFC7542] 🦋 this spec explains how to use the NAI to proxy CoA packets across multiple hops ✨ other ways to proxy CoA packets exist too, but we're skipping them here 🙈

to figure out the "next hop" for a packet, the proxying server looks up the "realm" part of the NAI in a logical Authentication, Authorization, and Accounting (AAA) routing table, as described in Section 3 of [RFC7542] 🗺️ the entry in that table holds info about the next hop the packet gets sent to 📬 that info can be an IP address, a shared secret, a certificate, and so on 🔐 the next hop might be another proxy, or it might be the home server for that realm 🏡

if the next hop is a proxy, that proxy does the same realm lookup and then proxies the packet along like before 🔁 eventually, the next hop will be the home server for that realm 👑

the home server checks the NAI in the User-Name attribute against the list of realms hosted by the home network 🔍 if nothing matches, an Access-Reject gets sent back 🙅‍♀️ everything else gets handled by local site rules, which produce an appropriate response packet 💌 that response can be an Access-Accept, an Access-Challenge, or an Access-Reject 🎀

the RADIUS client that gets that response matches it to an outstanding request 🎯 if that client is part of a proxy, the proxy then sends the response on to the system that started the Access-Request 🔁 this keeps going until the response reaches the NAS 🏁

proxies are usually stateful about ongoing request/response packets, but stateless when it comes to user sessions 🧠 once a proxy has sent a response, it can throw away everything it knew about the request packet, except what it needs to detect retransmissions as per Section 2.2.2 of [RFC5080] 🗑️✨

the same method is used to proxy Accounting-Request packets 📊 proxying both Access-Request and Accounting-Request packets lets proxies connect visited networks to home networks for all AAA purposes 💜

2.2. CoA Processing

[RFC5176] describes how CoA clients send packets to CoA servers 📤 we should note that the system with the CoA client is usually co-located with the RADIUS server, or is the same system as the RADIUS server 🖥️ similarly, the CoA server is a system that's either co-located with the RADIUS client or is the same system as the RADIUS client 🔄

when packets are sent inside one network, the source and destination of the CoA packets are determined locally 🏠 so there's no need to standardize that process, since networks are free to send CoA packets whenever they want, for whatever reason they want 🦋💅

2.3. Failure of CoA Proxying 💔

okay so proxies make this way messier 😭. [RFC5176] says CoA proxying is permitted, but it never explains how that proxying is supposed to work 🫠.

If proxies tracked user sessions, a proxy could match an incoming CoA packet to a user session and then proxy the CoA packet back to the RADIUS client that sent the Access-Request for that session. There are a lot of problems with that, bestie 💀.

The CoA server might not be on the same box as the RADIUS client. If that's the case, it might not have the user session info it needs to do the reverse path forwarding 🙃.

The CoA server could be down, but a different CoA server might be able to handle the packet just fine. The CoA client should then fail over to a different CoA server 🔁. If the reverse path has to match the forward path, though, failover is not possible 🚫.

In a roaming consortium, proxies might forward traffic for tens of millions of users 🤯. Tracking every session is expensive and complicated, and it doesn't scale well. That's why most proxies don't record user sessions 💅.

Even if a proxy did record sessions, [RFC5176] never says which attributes count as "session identification attributes" 🤷‍♀️. So a proxy can't tell whether a CoA packet matches a particular user session. Impossible, no cap.

All of this adds up to one big plot twist: CoA proxying is impossible when using the behavior defined in [RFC5176] 😭💔.

3. How to Perform CoA Proxying 🦋

The fix is realm-based proxying on the reverse path, just like on the forward path 👑. For reverse path proxying to work, the proxy decision has to be based on an attribute other than User-Name.

Reverse path proxying can use the Operator-Name attribute from Section 4.1 of [RFC5580] 🧩. Here's that definition again so we're all on the same page:

"This attribute carries the operator namespace identifier and the operator name. The operator name is combined with the namespace identifier to uniquely identify the owner of an access network."

A few paragraphs later, the REALM namespace gets described:

REALM ('1' (0x31)): The REALM operator namespace can be used to indicate operator names based on any registered domain name. Such names are required to be unique, and the rights to use a given realm name are obtained coincident with acquiring the rights to use a particular Fully Qualified Domain Name (FQDN). ...

So basically, Operator-Name holds an ASCII 1 followed by the realm of the visited network. For the "example.com" realm, Operator-Name contains the text 1example.com. That's exactly the info intermediate nodes need to do CoA proxying 🎯.

The rest of this doc covers CoA proxying with Operator-Name. We're going over:

  • how the forward path has to change so reverse path proxying is allowed
  • how reverse path proxying works
  • how visited networks and home networks have to behave for CoA proxying to work

Quick note: a proxied CoA packet only goes to one destination, so Operator-Name MUST NOT occur more than once in a packet 🙅. If a packet contains more than one Operator-Name, implementations MUST treat the second and subsequent attributes as "invalid attributes", as discussed in Section 2.8 of [RFC6929] ⚠️.

3.1. Changes to Access-Request and Accounting-Request Packets 📝

When a visited network proxies an Access-Request or Accounting-Request packet outside its network, a visited network that wants realm-based CoA proxying SHOULD include an Operator-Name attribute in the packet, as discussed in Section 4.1 of [RFC5580]. The contents of Operator-Name should be "1", followed by the realm name of the visited network. If the visited network has more than one realm name, a "canonical" name SHOULD be chosen and used for all packets.

Visited networks MUST use a consistent value for Operator-Name for any one user session. Sending 1example.com in an Access-Request packet and 1example.org in an Accounting-Request packet for that same session is forbidden. That would make it look like one user session was active at the same time in two different visited networks, which is impossible 🙃.

Proxies that record user session information SHOULD also record Operator-Name. Proxies that don't record user session information don't need to record Operator-Name 🧾.

Home networks SHOULD record Operator-Name along with any other info they record about user sessions. Home networks that expect to send CoA packets to visited networks MUST record Operator-Name for each user session that originates from a visited network. If they don't, the home network won't know where to send any CoA packets 😬.

Networks that host both the RADIUS client and RADIUS server don't need to create, record, or track Operator-Name. So if the visited and home networks are the same, there's no need to use the Operator-Name attribute 🏠.

3.2. Proxying of CoA-Request and Disconnect-Request Packets 🔀

When a home network wants to send a CoA-Request or Disconnect-Request packet to a visited network, it MUST include an Operator-Name attribute in the CoA packet. The value of Operator-Name MUST be the value that was recorded earlier for that user session.

The home network MUST look up the realm from Operator-Name in a logical "realm routing table", as discussed in Section 3 of [RFC7542]. That logical realm table is defined there as:

"... a logical AAA routing table, where the "utf8-realm" portion acts as a key, and the values stored in the table are one or more "next hop" AAA servers."

To support CoA proxying, this table gets extended to map "utf8-realm" to one or more next-hop CoA servers.

When proxying CoA-Request and Disconnect-Request packets, the lookups return data from the "CoA server" field instead of the "AAA server" field.

In practice, CoA proxying works exactly like "normal" RADIUS proxying, except the proxy decision uses the realm from Operator-Name instead of the realm from User-Name 🪄.

Proxies that receive the CoA packet look up the realm from Operator-Name in a logical "realm routing table", just like home servers do (above). The packet then goes to the proxy for the realm found in that table. This keeps going through any subsequent proxies until the packet reaches a public CoA server at the visited network 🛤️.

If the realm is unknown, the proxy MUST return a NAK packet that contains an Error-Cause Attribute having value 502 ("Request Not Routable").

Proxies that receive a CoA packet MUST NOT use the NAI from the User-Name attribute to make proxying decisions. Doing that would send the CoA packet to the home network while the user's session is in the visited network 🚨.

We also update Section 5 of [RFC5580] to permit CoA-Request and Disconnect-Request packets to contain zero or one instance of the Operator-Name attribute.

3.3. Reception of CoA-Request and Disconnect-Request Packets 📬

After some proxying, the CoA packet gets received by the CoA server in the visited network. That CoA server MUST validate the NAI in the Operator-Name attribute against the list of realms hosted by the visited network. If the realm isn't found, the CoA server MUST return a NAK packet that contains an Error-Cause Attribute having value 502 ("Request Not Routable").

Some home networks won't have permission to send CoA packets to the visited network. So the CoA server SHOULD also validate the NAI contained in the User-Name attribute. If the home network isn't permitted to send CoA packets to this visited network, the CoA server MUST return a NAK packet that contains an Error-Cause Attribute having value 502 ("Request Not Routable").

These checks make it harder for a malicious home network to scan roaming networks and figure out which visited network hosts which realm 🕵️. That info should be known to all parties in advance and shared through methods outside the scope of this specification 🤝. Those methods will usually be contracts between parties or membership in a roaming consortium.

The CoA server in the visited network also makes sure the Operator-NAS-Identifier attribute is known, as described below. If the attribute matches a known NAS, the packet goes to that NAS. Otherwise, the CoA server MUST return a NAK packet that contains an Error-Cause Attribute having value 403 ("NAS Identification Mismatch") 🚫.

All other received packets get processed according to local site rules, and an appropriate response packet gets sent. This mirrors the way Access-Request and Accounting-Request packets are processed (described above) 🪞.

Processing in the visited network normally includes sending the CoA packet to the NAS, having the NAS process it, and then returning any response packets back up the proxy chain to the home server 🔙.

The only missing piece is how the visited network gets the packet from its public CoA server to the NAS. It could use NAS-Identifier, NAS-IP-Address, or NAS-IPv6-Address, but those attributes may have been edited by an intermediate proxy, or they may be missing entirely 🫥.

Those attributes can be wrong because proxies forwarding Access-Request packets often rewrite them for internal policy reasons. They can also be missing because the visited network may not want every upstream proxy and home server to have detailed info about its private network, so it may remove them itself 🔒.

So we need a way to identify a NAS in the visited network that affords privacy and doesn't use any existing attributes 💜. Our solution is to define an Operator-NAS-Identifier attribute, which identifies an individual NAS in the visited network ✨.

3.4. Operator-NAS-Identifier 🦋

okay bestie, so the Operator-NAS-Identifier attribute is an opaque token that identifies one individual NAS inside a visited network 🧚 It MAY show up in the following packets: Access-Request, Accounting-Request, CoA-Request, or Disconnect-Request. It MUST NOT appear in any other packets, no exceptions 🙅‍♀️

Operator-NAS-Identifier MAY occur in a packet if that packet also has an Operator-Name attribute. It MUST NOT appear in a packet with no Operator-Name in it. Each proxied CoA packet only goes to ONE NAS, so Operator-NAS-Identifier MUST NOT occur more than once in a packet 💅 If a packet has more than one, implementations MUST treat the second and subsequent attributes as "invalid attributes", as discussed in Section 2.8 of [RFC6929]. Iykyk 💀

An Operator-NAS-Identifier attribute SHOULD be added to an Access-Request or Accounting-Request packet by a visited network, before the packet gets proxied to an external RADIUS server ✨ When that attribute gets added, the following attributes SHOULD be deleted from the packet: NAS-IP-Address, NAS-IPv6-Address, and NAS-Identifier. If those get deleted, the proxy MUST then add a new NAS-Identifier attribute, so it still meets the requirements of Section 4.1 of [RFC2865] and Section 4.1 of [RFC2866]. The contents of that new NAS-Identifier SHOULD be the realm name of the visited network 🌸

When a server gets a packet that already has an Operator-NAS-Identifier attribute, no editing like that happens. 🙈

The Operator-NAS-Identifier attribute MUST NOT be added to any packet by any other proxy or server in the network. Only the visited network (aka the operator) can name a NAS that lives inside the visited network 👑

So the result of all these rules is that, for everyone outside the visited network, there is only ONE NAS, and that's the visited network itself 🫶 The visited network also gets to identify its own NASes however it wants, and that's totally its business. Main character energy for the visited network 💜

This usage of the Operator-NAS-Identifier attribute parallels the Operator-Name attribute as defined in Section 4.1 of [RFC5580] 🧚‍♀️

The Operator-NAS-Identifier attribute is defined as follows 🎀

Description

An opaque token describing the NAS a user has logged into.

Type

241.8 (assigned by IANA from the "short extended space" [RFC6929] of the "RADIUS Attribute Types" registry).

Length

4 to 35.

Implementations supporting this attribute MUST be able to handle between one (1) and thirty-two (32) octets of data. Implementations creating an Operator-NAS-Identifier attribute MUST NOT create attributes with more than sixty-four (64) octets of data. A 32-octet string should be more than sufficient for future uses 🍓

Data Type

The data type of this field is "string". See Section 3.5 of [RFC8044] for a definition.

Value

This attribute contains an opaque token that can only be interpreted by the visited network 🔐

This token MUST allow the visited network to direct the packet to the NAS for the user's session. In practice, this requirement means the visited network has two practical methods for creating the value 🧠

The first method is to create an opaque token per NAS and then store that info in a database. The database can be set up to allow querying by NAS IP address, so you can find the correct Operator-NAS-Identifier. The database can also be set up to allow querying by Operator-NAS-Identifier, so you can find the correct NAS IP address 📚

The second method is to obfuscate the NAS IP address using information the visited network knows locally. For example, you could XOR it with a locally known secret key. The output of that obfuscation operation is data that can be used as the value of Operator-NAS-Identifier. When a CoA packet is received, the locally known information can be used to unobfuscate the value of Operator-NAS-Identifier, so the actual NAS IP address can be determined 🪄

Note that there is no requirement that the value of Operator-NAS-Identifier be checked for integrity. Modifying the value can only result in the erroneous transaction being rejected 🙃

We note that the Access-Request and Accounting-Request packets often contain the Media Access Control (MAC) address of the NAS. There is therefore no requirement that Operator-NAS-Identifier obfuscate or hide in any way the total number of NASes in a visited network. That info is already public knowledge 🌈

4. Requirements 🎀

4.1. Requirements on Home Servers 🏠

The Operator-NAS-Identifier attribute MUST be stored by a home server along with any user session identification attributes 💾 When sending a CoA packet for a user session, the home server MUST include verbatim any Operator-NAS-Identifier it has recorded for that session.

A home server MUST NOT send CoA packets for users of other networks. The next few sections describe how other participants in the RADIUS ecosystem can help enforce this requirement 👀

4.2. Requirements on Visited Networks 🏡

A visited network that receives a CoA packet that will be proxied to a NAS MUST perform all of the operations required for proxies; see Section 4.3.2. We specify this requirement because we assume the visited network has a proxy between the NAS and any external (i.e., third-party) proxy. Situations where a NAS sends packets directly to a third-party RADIUS server are outside the scope of this specification 🚫

The visited network uses the contents of the Operator-NAS-Identifier attribute to determine which NAS will receive the packet 📬

The visited network MUST remove the Operator-Name and Operator-NAS-Identifier attributes from a given CoA packet prior to sending that packet to the final CoA server (i.e., NAS). This step is necessary due to the limits specified in Section 2.3 of [RFC5176] 🧹

The visited network MUST also ensure that the CoA packet sent to the NAS contains one of the following attributes: NAS-IP-Address, NAS-IPv6-Address, or NAS-Identifier. This step is the inverse of the removal suggested above in Section 3.4 🔄

In general, the NAS should only receive attributes that identify or modify a user's session. It is not appropriate to send a NAS attributes that are used only for inter-proxy signaling 🤫

4.3. Requirements on Proxies 🧚

There are a number of requirements on both CoA proxies and RADIUS proxies. For the purpose of this section, we assume that each RADIUS proxy shares a common administration with a corresponding CoA proxy, and that the two systems can communicate electronically. There is no requirement that these systems be co-located 🌸

4.3.1. Security Requirements on Proxies 🔒

Section 6.1 of [RFC5176] has some security requirements on proxies that handle CoA-Request and Disconnect-Request packets:

... a proxy MAY perform a "reverse path forwarding" (RPF) check to verify that a Disconnect-Request or CoA-Request originates from an authorized Dynamic Authorization Client.

We strengthen that requirement by saying that a proxy MUST perform a reverse path forwarding check to verify that a CoA packet originates from an authorized Dynamic Authorization Client. Without this check, a proxy may forward packets from misconfigured or malicious parties and thus contribute to the problem instead of preventing it 😱 Where the check fails, the proxy MUST return a NAK packet that contains an Error-Cause Attribute having value 502 ("Request Not Routable").

Proxies that record user session information SHOULD verify the contents of a received CoA packet against the recorded data for that user session. If the proxy determines that the information in the packet does not match the recorded user session, it SHOULD return a NAK packet that contains an Error-Cause Attribute having value 503 ("Session Context Not Found"). These checks cannot be mandated due to the fact that [RFC5176] offers no advice on which attributes are used to identify a user's session 🤷‍♀️

Because a RADIUS proxy will see Access-Request and Accounting-Request packets, we recognize that it will have sufficient information to forge CoA packets. The RADIUS proxy will thus have the ability to subsequently disconnect any user who was authenticated through itself 💀

We suggest that the real-world effect of this security problem is minimal. RADIUS proxies can already return Access-Accept or Access-Reject for Access-Request packets, and can change authorization attributes contained in an Access-Accept. Allowing a proxy to change (or disconnect) a user session post-authentication is not substantially different from changing (or refusing to connect) a user session during the initial process of authentication 🙄

The biggest problem is that there are no provisions in RADIUS for "end-to-end" security. That is, the visited network and home network cannot communicate privately in the presence of proxies. This limitation originates from the design of RADIUS for Access-Request and Accounting-Request packets, and that limitation is then carried over to CoA-Request and Disconnect-Request packets 😭

We therefore cannot prevent proxies or home servers from forging CoA packets. We can only create scenarios where that forgery is hard to perform, is likely to be detected, and/or has no effect 🫠

4.3.2. Filtering Requirements on Proxies ✨

okay so bestie, this bit is about what proxies have to do with the attributes they're handed 💅 Section 2.3 of [RFC5176] says that for CoA servers, "In CoA-Request and Disconnect-Request packets, all attributes MUST be treated as mandatory." 🎀 But that's way too strict for a CoA proxy 😭 Only the final CoA server (aka the NAS) actually knows which attributes are mandatory and which ones aren't, so proxies get a pass here.

So for a CoA proxy, the rule flips: all attributes MUST NOT be treated as mandatory 🦋 Proxies that do this spec MUST do their proxying based on Operator-Name 💜 (other schemes exist, but we're not talking about them here). And proxies SHOULD forward all packets either "as is" or with minimal changes 🌸

Lowkey some NAS implementations are already doing the mandatory thing anyway 💀 Like, some of them will NAK any CoA packet that has a Proxy-State attribute. Technically that's just a literal reading of the text above, but it causes real problems in practice, so... not it 🙈

Here's the update to Section 2.3 of [RFC5176]: in CoA-Request and Disconnect-Request packets, the NAS MUST NOT treat as mandatory any attribute that is known to not affect the user's session, for example the Proxy-State attribute. Proxy-State is used for proxy-to-proxy signaling, and since it can't affect the user's session, Proxy-State (and similar attributes) MUST be ignored by the NAS ✨ Main character energy for the NAS to just chill about it.

When a proxy receives Operator-Name and/or Operator-NAS-Identifier, it MUST pass those attributes through unchanged 🍓 This applies to ALL proxies, including the ones forwarding Access-Request, Accounting-Request, CoA-Request, and Disconnect-Request packets, no exceptions bestie 👑

Any attributes a RADIUS proxy adds when sending packets from the visited network to the home network MUST be removed by the matching CoA proxy on the reverse path 🧚 In other words, any editing done on the "forward" path MUST be undone on the "reverse" path. Clean up after yourself, always 🫶

The result is that a NAS will only ever get CoA packets that contain either (1) attributes the NAS itself sent to its local RADIUS server, or (2) attributes the home server sent in order to do a change of authorization. So no random extras showing up, iconic 🌈

Finally, we extend all of this not just to Operator-Name and Operator-NAS-Identifier, but also to any future attributes added for proxy-to-proxy signaling 🔥

5. Functionality 🎀

okay this section is where the two attributes team up to make CoA proxying happen, and honestly it's so cute 🥹

5.1. User Login 🌸

so picture a roaming user trying to log in to a visited network 🧳 They do it through a NAS in that visited network, and the NAS sends an Access-Request packet to the visited RADIUS server. The visited RADIUS server notices the user is roaming and adds an Operator-Name attribute, with the value "1" followed by its own realm name, like "1example.com" 💖 The visited RADIUS server MAY also add an Operator-NAS-Identifier attribute 🦋 And the NAS identification attributes get edited too, as required by Section 3.4, above ✨

Then the visited server proxies the auth request upstream 🚀 That upstream server might be the home server, or it might be another proxy. If it's a proxy, the proxy keeps forwarding the packet until it reaches the home server 💜

When the home server gets the packet, it records the Operator-Name and Operator-NAS-Identifier attributes, along with other info about the user's session, as long as those attributes are actually in the packet 📝✨

5.2. CoA Proxying 🦋

so later on, the home server figures out that either (1) a user session needs its authorization changed, or (2) the user needs to be disconnected 😳 The home server looks up the Operator-Name and Operator-NAS-Identifier attributes, along with the other user session identifiers described in [RFC5176] 💅 Then it looks up the realm from Operator-Name in the logical AAA routing table, to find the next-hop CoA server for that realm (which might be a proxy) 🗺️ And then the CoA-Request gets sent to that CoA server 📬

The CoA server gets the request and, if it's a proxy, does a lookup similar to the one the home server did 🔍 The packet keeps getting proxied until it reaches the visited network 🌈

Now, if the proxy can't find a destination for the request, or if there's no Operator-Name attribute in the request at all, the proxy sends back a CoA-NAK with Error-Cause 502 ("Request Not Routable") 💀

The visited network gets the CoA-Request packet and uses the Operator-NAS-Identifier attribute (if it's there) to figure out which local CoA server (aka NAS) the packet should go to 🎯 If there's no Operator-NAS-Identifier, the visited network can use other means to find the NAS, like checking a local database that tracks user sessions 🗄️

Then the Operator-Name and Operator-NAS-Identifier attributes get removed from the packet 🧹 One of NAS-IP-Address, NAS-IPv6-Address, or NAS-Identifier gets added instead, and the packet is sent on to the CoA server 📦

If no CoA server can be found, the visited network returns a CoA-NAK with Error-Cause 403 ("NAS Identification Mismatch") 🙈

And any response from the CoA server (the NAS) goes back to the home network the usual way responses get returned to requests 💌

6. Security Considerations 🔐

okay this part is SERIOUS bestie, so let's be real about it 😤 This specification incorporates by reference Section 11 of [RFC6929]. Short version: RADIUS has a lot of known issues, all discussed in detail in [RFC6929], so we don't need to repeat them here 📚

This spec adds one new attribute and defines new behavior for RADIUS proxying 🚨 Since this behavior mirrors existing RADIUS proxying, we don't believe it introduces any new security issues. BUT we do note that RADIUS proxying has many inherent security issues, so don't get too comfy 🥶

6.1. RADIUS Security and Proxies 🛡️

The requirement that packets be signed with a shared secret means a CoA packet can only be received from a trusted party, or, transitively, from a third party via a trusted party 🔑 This security feature of base RADIUS makes it impossible for untrusted parties to affect the user's session 🙅‍♀️

When RADIUS proxying happens, all packets are signed on a hop-by-hop basis 🔗 That means any intermediate proxy can forge packets, replay packets, or modify the contents of any packet 😱 Any system that receives correctly signed packets has to accept them at face value, and can't detect any forgery, replay, or modifications 🫠 So the secure operation of such a system depends largely on trust instead of on technical means 🤝

CoA packet proxying has all of the same issues as those noted above ⚠️ The proxies that can see and modify CoA packets are generally the same proxies that can see or modify Access-Request and Accounting-Request packets 👀 So there are few additional security implications in allowing CoA proxying ✨

The main security implication that remains is that home networks now have the ability to disconnect or change the authorization of users in a visited network 👑 But this capability only gets enabled when mutual agreement is in place, and only for parties who can already control user sessions, so there are no new security issues with this specification 💅

6.2. Security of the Operator-NAS-Identifier Attribute 🤫

Nothing in this specification depends on the security of the Operator-NAS-Identifier attribute 🙌 The whole process would work exactly the same if Operator-NAS-Identifier just contained the NAS IP address hosting the user's session 🖥️ The only real downside would be that external parties would see some extra private info about the visited network 👀 They still wouldn't be able to use that info to do anything malicious 🫶

The main reason to use an opaque token for Operator-NAS-Identifier is that there's no compelling reason to make the info public 🔒 So we recommend that the value be simply an opaque token 🎟️ We also state that there's no requirement for integrity protection or replay detection of this attribute 🤷‍♀️ The rest of the RADIUS protocol makes sure that modifying or replaying Operator-NAS-Identifier either has no effect or has the same effect as if the value hadn't been modified 🔁

Trusted parties can only modify a user's session on the NAS when they have enough info to identify that session 🎯 In practice, that means those parties already have access to the user's session information 💁‍♀️ In other words, they're the proxies already forwarding Access-Request and Accounting-Request packets 📨

Since those parties already can see and modify everything about a user's session, there's no additional security issue with letting them see and modify CoA packets 🥂

In short, any security issues with the contents of Operator-NAS-Identifier are largely limited by the security of the underlying RADIUS protocol 🧱 So it doesn't matter how the values of Operator-NAS-Identifier are created, stored, or used 🙆‍♀️

7. IANA Considerations 📋

okay so per Section 3.4 of this document, IANA has allocated one new RADIUS attribute (the Operator-NAS-Identifier attribute) from the "short extended space" of the "RADIUS Attribute Types" registry, like this 🎀

Value: 241.8
Description: Operator-NAS-Identifier
Data Type: string
Reference: RFC 8559

8. References 📚

8.1. Normative References 📚✨

the heavy-hitter references, bestie 💅 here they are, in full glory:

8.2. Informative References 🦋

the bonus reads, and still very much worth a look 🌸

Authors' Addresses 🎀

meet the brains behind the spec 🧚💜

Alan DeKok
The FreeRADIUS Server Project

   Email: aland@freeradius.org


Jouni Korhonen

   Email: jouni.nospam@gmail.com
📦 where this page comes from