Network Working Group DeKok, Alan INTERNET-DRAFT FreeRADIUS Updates: 5176 J. Korhonen Category: Standards Track 16 August 2018 Dynamic Authorization Proxying in Remote Authorization Dial-In User Service Protocol (RADIUS) draft-ietf-radext-coa-proxy-07.txt Abstract RFC 5176 defines Change of Authorization (CoA) and Disconnect Message (DM) behavior for RADIUS. That document suggests that proxying these messages is possible, but gives no guidance as to how it is done. This specification updates RFC 5176 to correct that omission for scenarios where networks use Realm-based proxying as defined in RFC 7542. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on February 16, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. DeKok, Alan Proposed Standard [Page 1] INTERNET-DRAFT Dynamic Authorization Proxying in RADIUS 16 August 2018 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info/) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. DeKok, Alan Proposed Standard [Page 2] INTERNET-DRAFT Dynamic Authorization Proxying in RADIUS 16 August 2018 Table of Contents 1. Introduction ............................................. 4 1.1. Terminology ......................................... 4 1.2. Requirements Language ............................... 5 2. Problem Statement ........................................ 6 2.1. Typical RADIUS Proxying ............................. 6 2.2. CoA Processing ...................................... 7 2.3. Failure of CoA Proxying ............................. 7 3. How to Perform CoA Proxying .............................. 8 3.1. Changes to Access-Request and Accounting-Request pack 8 3.2. Proxying of CoA-Request and Disconnect-Request packet 9 3.3. Reception of CoA-Request and Disconnect-Request packe 10 3.4. Operator-NAS-Identifier ............................. 11 4. Requirements ............................................. 13 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 DeKok, Alan Proposed Standard [Page 3] INTERNET-DRAFT Dynamic Authorization Proxying in RADIUS 16 August 2018 1. Introduction RFC 5176 [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 gives no guidance as to how that is done. This omission means that in practice, proxying of CoA packets is impossible. We partially correct that ommission here by explaining how proxying of these packets can be done by leveraging an existing RADIUS attribute, Operator-Name (Section 4.1 of [RFC5580]). We then explain how this attribute can be used by proxies to route packets "backwards" through a RADIUS proxy chain from a Home Network to a Visited Network. We then introduce a new attribute; Operator-NAS- Identifier. This attribute permits packets to be routed from the RADIUS server at the Visited Network to the NAS. This correction is limited to the use-case of Realm-based proxying as defined in [RFC7542]. Other forms of proxying are possible, but are not discussed here. We conclude with a discussion of the security implications of the design, and show that they do not decrease the security of the network. 1.1. Terminology This document frequently uses the following terms: CoA Change of Authorization, e.g. CoA-Request, or CoA-ACK, or CoA-NAK, as defined in [RFC5176]. That specification also defines Disconnect-Request, Disconnect-ACK, and Disconnect-NAK. For simplicity here, where we use "CoA", we mean a generic "CoA- Request or Disconnect-Request" packet. We use "CoA-Request" or "Disconnect-Request" to refer to the specific packet types. Network Access Identifier The Network Access Identifier (NAI) [RFC7542] is the user identity submitted by the client during network access authentication. The purpose of the NAI is to identify the user as well as to assist in the routing of the authentication request. Please note that the NAI may not necessarily be the same as the user's email address or the user identity submitted in an application layer authentication. DeKok, Alan Proposed Standard [Page 4] INTERNET-DRAFT Dynamic Authorization Proxying in RADIUS 16 August 2018 Network Access Server The Network Access Server (NAS) is the device that clients connect to in order to get access to the network. In Point to Point Tunneling Protocol (PPTP) terminology, this is referred to as the PPTP Access Concentrator (PAC), and in Layer 2 Tunneling Protocol (L2TP) terminology, it is referred to as the L2TP Access Concentrator (LAC). In IEEE 802.11, it is referred to as an Access Point. Home Network The network which holds the authentication credentials for a user. Visited Network A network other than the home network, where the user attempts to gain network access. The Visited Network typically has a relationship with the Home Network, possibly through one or more intermediary proxies. 1.2. Requirements Language 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 interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. DeKok, Alan Proposed Standard [Page 5] INTERNET-DRAFT Dynamic Authorization Proxying in RADIUS 16 August 2018 2. Problem Statement This section describes how RADIUS proxying works, how CoA packets work, and why CoA proxying as discussed in [RFC5176] is insufficient to create a working system. 2.1. Typical RADIUS Proxying When a RADIUS server proxies an Access-Request packet, it typically does so based on the contents of the User-Name attribute, which contains a Network Access Identifier (NAI) [RFC7542]. This specification describes how to use the NAI in order to proxy CoA packets across multiple hops. Other methods of proxying CoA packets are possible, but are not discussed here. In order to determine the "next hop" for a packet, the proxying server looks up the "Realm" portion of the NAI in a logical AAA routing table, as described in Section 3 of [RFC7542]. The entry in that table contains information about the "next hop" to which the packet is sent. This information can be IP address, shared secret, certificate, etc. The "next hop" may also be another proxy, or it may be the Home Server for that realm. If the "next hop" is a proxy, that proxy will perform the same Realm lookup, and then proxy the packet as above. At some point, the "next hop" will be the Home Server for that realm. The Home Server validates the NAI in the User-Name attribute against the list of Realms hosted by the Home Network. If there is no match, then an Access-Reject is returned. All other packets are processed through local site rules, which result in an appropriate response packet being sent. This response packet can be Access-Accept, Access-Challenge, or Access-Reject. The RADIUS client receiving that response packet will match it to an outstanding request. If the client is part of a proxy, the proxy will then send that response packet in turn to the system that originated the Access-Request. This process occurs until the response packet arrives at the NAS. The proxies are typically stateful with respect to ongoing request / response packets, but stateless with respect to user sessions. That is, once a response has been sent by the proxy, it can discard all information about the request packet, other than what is needed for detecting retransmissions as per Section 2.2.2 of [RFC5080]. The same method is used to proxy Accounting-Request packets. The combination of the two methods allows proxies to connect Visited DeKok, Alan Proposed Standard [Page 6] INTERNET-DRAFT Dynamic Authorization Proxying in RADIUS 16 August 2018 Networks to Home Networks for all AAA purposes. 2.2. CoA Processing [RFC5176] describes how CoA clients send packets to CoA servers. We note that system comprising the CoA client is typically co-located with, or is the same as, the RADIUS server. Similarly, the CoA server is a system that is either co-located with, or is the same as, the RADIUS client. In the case of packets sent inside of one network, the source and destination of CoA packets are locally determined. There is thus no need for standardization of that process, as networks are free to send CoA packets whenever they want, for whatever reason they want. 2.3. Failure of CoA Proxying The situation is more complicated when proxies are involved. [RFC5176] suggests that CoA proxying is permitted, but that specification makes no suggestions for how that proxying should be done. If proxies were to track user sessions, it would be possible for a proxy to match an incoming CoA packet to a user session, and then to proxy the CoA packet to the RADIUS client that originated the Access- Request for that session. There are many problems with such a scenario. The CoA server may, in fact, not be co-located with the RADIUS client. In which case it may not have access to user session information for performing the reverse path forwarding. The CoA server may be down, but there may be a different CoA server which could successfully process the packet. The CoA client should then fail over to a different CoA server. If the reverse path is restricted to be the same as the forward path, then such fail-over is not possible. In a roaming consortium, the proxies may forward traffic for tens of millions of users. Tracking each user session can be expensive and complicated, and doing so does not scale well. For that reason, most proxies do not record user sessions. Even if the proxy recorded user sessions, [RFC5176] is silent on the topic of what attributes constitute "session identification attributes". That silence means it is impossible for a proxy to determine if a CoA packet matches a particular user session. DeKok, Alan Proposed Standard [Page 7] INTERNET-DRAFT Dynamic Authorization Proxying in RADIUS 16 August 2018 The result of all of these issues is that CoA proxying is impossible when using the behavior defined in [RFC5176]. 3. How to Perform CoA Proxying The solution to the above problem is to use Realm-based proxying on the reverse path, just as with the forward path. In order for the reverse path proxying to work, the proxy decision must be based on an attribute other than User-Name. The reverse path proxying can be done by using the Operator-Name attribute defined in [RFC5580], Section 4.1. We repeat a portion of that definition here for clarity: 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. Followed by a description of the REALM namespace: 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). ... In short, the Operator-Name attribute contains the an ASCII "1", followed by the Realm of the Visited Network. e.g. for the "example.com" realm, the Operator-Name attribute contains the text "1example.com". This information is precisely what is needed by intermediate nodes in order to perform CoA proxying. The remainder of this document describes how CoA proxying can be performed by using the Operator-Name attribute. We describe how the forward path has to change in order to allow reverse path proxying. We then describe how reverse path proxying works. And we describe how Visited Networks and Home Networks have to behave in order for CoA proxying to work. 3.1. Changes to Access-Request and Accounting-Request packets When a Visited Network proxies an Access-Request or Accounting- Request packet outside of its network, the Visited Network SHOULD include an Operator-Name attribute in the packet, as discussed in Section 4.1 of [RFC5580]. The contents of the Operator-Name should be "1", followed by the realm name of the Visited Network. Where the DeKok, Alan Proposed Standard [Page 8] INTERNET-DRAFT Dynamic Authorization Proxying in RADIUS 16 August 2018 Visited Network has more than one realm name, a "canonical" one SHOULD be chosen, and used for all packets. Visited Networks MUST use a consistent value for Operator-Name for any one user session. That is, sending "1example.com" in an Access- Request packet, and "1example.org" in an Accounting-Request packet for that same session is forbidden. Such behavior would make it look like a single user session was active simultaneously in two different Visited Networks, which is impossible. Proxies that record user session information SHOULD also record Operator-Name. Proxies that do not record user session information do not need to record Operator-Name. Home Networks SHOULD record Operator-Name along with any other information that 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. Failure to record the Operator-Name would mean that the Home Network would not know where to send any CoA packet. Networks that host both the RADIUS client and RADIUS server do not need to create, record or track Operator-Name. That is, if the Visited Network and Home Network are the same, there is no need to use the Operator-Name attribute. 3.2. Proxying of CoA-Request and Disconnect-Request packets When a Home Network wishes 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 the Operator-Name MUST be the value which was recorded earlier for that user session. The Home Network MUST lookup the realm from the Operator-Name in a logical "realm routing table", as discussed in [RFC7542] Section 3. 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. In order to support proxying of CoA packets, this table is extended to include a mapping between "utf8-realm" and one or more "next hop" CoA servers. When proxying CoA-Request and Disconnect-Request packets, the lookups will return data from the "CoA server" field, instead of the "AAA server" field. DeKok, Alan Proposed Standard [Page 9] INTERNET-DRAFT Dynamic Authorization Proxying in RADIUS 16 August 2018 In practice, this process means that CoA proxying works exactly like "normal" RADIUS proxying, except that the proxy decision is made using the realm from the Operator-Name attribute, instead of using the realm from the User-Name attribute. Proxies that receive the CoA packet will look up the realm from the Operator-Name in a logical "realm routing table", as with Home Servers, above. The packet is then sent to the proxy for the realm which was found in that table. This process continues with any subsequent proxies until the packet reaches a public CoA server at the Visited Network. Where the realm is unknown, the proxy MUST return a NAK packet that contains an Error-Cause attribute having value 502 ("Request Not Routable"). Proxies which receive a CoA packet MUST NOT use the NAI from the User-Name in order to make proxying decisions. Doing so would result in the CoA packet being forwarded 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 instances of the Operator-Name attribute. 3.3. Reception of CoA-Request and Disconnect-Request packets After some proxying, the CoA packet will be recieved 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 is not found, then the CoA server MUST return a NAK packet that contains an Error-Cause attribute having value 502 ("Request Not Routable"). Some Home Networks will not have permission to send CoA packets to the Visited Network. The CoA server SHOULD therefore also validate the NAI contained in the User-Name attribute. If the Home Network is not permitted to send CoA packets to this Visited Network, then the CoA server MUST return a NAK packet that contains an Error-Cause attribute having value 502 ("Request Not Routable"). These checks make it more difficult for a malicious Home Network to scan roaming network in order to determine which Visited Network hosts which Realm. That information should be known to all parties in advance, and exchanged via methods outside of this specification. Those methods will typically be in the form of contractual relationships between parties, or as membership in a roaming consortium. DeKok, Alan Proposed Standard [Page 10] INTERNET-DRAFT Dynamic Authorization Proxying in RADIUS 16 August 2018 The CoA server in the Visited Network will also ensure that the Operator-NAS-Identifier attribute is known, as described below. If the attribute matches a known NAS, then the packet will be sent 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 are processed as per local site rules, and will result in an appropriate response packet being sent. This process mirrors the method used to process Access-Request and Accounting-Request packets described above. The processing by Visited Network will normally include sending the CoA packet to the NAS; having the NAS process it; and then returning any response packet back up the proxy chain to the Home Server. The only missing piece here is the procedure by which the Visited Network gets the packet from its public CoA server to the NAS. The Visited Network could use NAS-Identifier, NAS-IP-Address, or NAS- IPv6-Address, but these attributes may have been edited by an intermediate proxy, or the attributes may be missing entirely. These attributes may be incorrect because proxies forwarding Access- Request packets often re-write them for internal policy reasons. These attributes may be missing, because the Visited Network may not want all upstream proxies and Home Servers to have detailed information about the internals of its private network, and may remove them itself. We therefore need a way to identify a NAS in the Visited Network, in a way which is both private, and which does not use any existing attribute. Our solution is to define an Operator-NAS-Identifier attribute, which identifies an individual NAS in the Visited Network. 3.4. Operator-NAS-Identifier The Operator-NAS-Identifier attribute is an opaque token that identifies an individual NAS in a Visited Network. It MAY appear in the following packets: Access-Request, Accounting-Request, CoA- Request, or Disconnect-Request. Operator-NAS-Identifier MUST NOT appear in any other packet. Operator-NAS-Identifier MAY occur in a packet if the packet also contains an Operator-Name attribute. Operator-NAS-Identifier MUST NOT appear in a packet if there is no Operator-Name in the packet. Operator-NAS-Identifier MUST NOT occur more than once in a packet. If a packet contains more than one Operator-NAS-Identifier, implementations MUST ignore the second and subsequent attributes, and DeKok, Alan Proposed Standard [Page 11] INTERNET-DRAFT Dynamic Authorization Proxying in RADIUS 16 August 2018 treat them as "invalid attributes", as discussed in Section 2.8 of [RFC6929]. An Operator-NAS-Identifer attribute SHOULD be added to an Access- Request or Accounting-Request packet by a Visited Network, before proxying a packet to an external RADIUS server. When the Operator- NAS-Identifer attribute is added to a packet, the following attributes MUST be deleted: NAS-IP-Address, NAS-IPv6-Address, NAS- Identifier. The proxy MUST then add a NAS-Identifier attribute, in order satisfy the requirements of Section 4.1 of [RFC2865], and Section 4.1 of [RFC2866]. The contents of the NAS-Identifier SHOULD be the Realm name of the visited network. When a server receives a packet that already contains an Operator- NAS-Identifer attribute, no such editing is performed. The Operator-NAS-Attribute MUST NOT be added to any packet by any other proxy or server in the network. Only the Visited Network (i.e. the operator) can name a NAS which is inside of the Visited Network. The result of these requirements is that for everyone outside of the Visited Network, there is only one NAS: the Visited Network itself. And, the Visited Network is able to identify its own NASes to its own satisfaction. This usage of the Operator-NAS-Identifier attribute parallels the Operator-Name attribute which was 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 TBD. To be assigned by IANA from the "short extended space". 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 MUST NOT create attributes with more than sixty-four octets of data. A thirty-two octet string should be more than sufficient for future DeKok, Alan Proposed Standard [Page 12] INTERNET-DRAFT Dynamic Authorization Proxying in RADIUS 16 August 2018 uses. Data Type string. See [RFC8044] Section 3.6 for a definition. Value The contents of this attribute are an opaque token interpretable only 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 that the Visited Network has two practical methods to create the value. The first method is to create an opaque token per NAS, and then to store that information in a database. The database can be configured to allow querying by NAS IP address in order to find the correct Operator-NAS-Identifier. The database can also be configured to allow querying by Operator-NAS-Identifier in order to find the correct NAS IP address. The second method is to obfuscate the NAS IP address using information known locally by the Visited network; for example, by XORing 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. On reception of a CoA packet, the locally-known information can be used to un-obfuscate the value of Operator-NAS-Identifier, in order to determine the actual NAS IP address. Note that there is no requirement that the value of Operator-NAS- Identifier be checked for integrity. Modification of the value can only result in the erroneous transaction being rejected. We note that the Access-Request and Accounting-Request packets often contain the MAC address of the NAS. There is therefore no requirement that Operator-NAS-Identifier obsfuscate or hide in any way the total number of NASes in a Visited Network. That information is already public knowledge. 4. Requirements DeKok, Alan Proposed Standard [Page 13] INTERNET-DRAFT Dynamic Authorization Proxying in RADIUS 16 August 2018 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 to enforce this requirement. 4.2. Requirements on Visited Networks A Visited Network which receives a CoA packet that will be proxied to a NAS MUST perform all of the operations required for proxies by Section 4.3.2. This requirement is because we assume that the Visited Network has a proxy in 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 of the scope of this specification. The Visited Network uses the content 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 any CoA packet packet prior to sending that packet to the final CoA server (i.e. NAS). This step is necessary due to the the limits of 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 required above in Section 3.4. In general, the NAS should only receive attributes which identify or modify a user's session. It is not appropriate to send a NAS attributes which are used only for inter-proxy signaling. 4.3. Requirements on Proxies There are a number of requirements on proxies, 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 for these systems to be co-located. DeKok, Alan Proposed Standard [Page 14] INTERNET-DRAFT Dynamic Authorization Proxying in RADIUS 16 August 2018 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" (RPF) 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 to identify a user's session. We recognize that because a RADIUS proxy will see Access-Request and Accounting-Request packets, 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 authentiction. The largest 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. That limitation is then carried over to CoA-Request and Disconnect-Request packets. DeKok, Alan Proposed Standard [Page 15] INTERNET-DRAFT Dynamic Authorization Proxying in RADIUS 16 August 2018 We cannot therefore prevent proxies or Home Servers from forging CoA packets. We can only create scenarios where that forgery is hard to perform, and/or is likely to be detected, and/or has no effect. 4.3.2. Filtering Requirements on Proxies Section 2.3 of [RFC5176] makes the following requirement for CoA servers: In CoA-Request and Disconnect-Request packets, all attributes MUST be treated as mandatory. These requirements are too stringent for a CoA proxy. Only the final CoA server (i.e NAS) can make a decision on which attributes are mandatory and which are not. Instead, we say that for a CoA proxy, all attributes MUST NOT be treated as mandatory. Proxies implementing this specification MUST perform proxying based on Operator-Name. Other schemes are possible, but are not discussed here. Proxies SHOULD forward all packets as- is, with minimal changes. We note that some NAS implementations currently treat signaling attributes as mandatory. For example, some NAS implementations will NAK any CoA packet that contains a Proxy-State attribute. While this behavior is based on a straightforward reading of the above text, it causes problems in practice. We update Section 2.3 of [RFC5176] to say that in CoA-Request and Disconnect-Request packets, the NAS MUST NOT treat as mandatory any attribute which is known to not affect the users session. For example, the Proxy-State attribute. Proxy-State is an attribute used for proxy-to-proxy signaling. It cannot affect the user's session, and therefore Proxy-State (and similar attributes) MUST be ignored by the NAS. When Operator-Realm and/or Operator-NAS-Identifier are received by a proxy, the proxy MUST pass those attributes through unchanged. This requirement applies to all proxies, including ones that forward any or all of Access-Request, Accounting-Request, CoA-Request, and Disconnect-Request packets. All attributes added by a RADIUS proxy when sending packets from the Visited Network to the Home Network Network MUST be removed by the corresponding CoA proxy from packets traversing the reverse path. That is, any attribute editing that is done on the "forward" path MUST be undone on the "reverse" path. DeKok, Alan Proposed Standard [Page 16] INTERNET-DRAFT Dynamic Authorization Proxying in RADIUS 16 August 2018 The result is that a NAS will only ever receive CoA packets that either contain attributes sent by the NAS to it's local RADIUS server, or contain attributes that are sent by the Home Server in order to perform a change of authorization. Finally, we extend the above requirement not only to Operator-Name and Operator-NAS-Identifier, but also to any future attributes that are added for proxy-to-proxy signaling. 5. Functionality This section describes how the two attributes work together to permit CoA proxying. 5.1. User Login In this scenario, we follow a roaming user who is attempting to log in to a Visited Network. The login attempt is done via a NAS in the Visited Network. That NAS will send an Access-Request packet to the visited RADIUS server. The visited RADIUS server will see that the user is roaming, and will add an Operator-Name attribute, with value "1" followed by it's own realm name. e.g. "1example.com". The visited RADIUS server MAY also add an Operator-NAS-Identifier. The NAS identification attributes are also edited, as required by Section 3.4, above. The Visited Server will then proxy the authentication request to an upstream server. That server may be the Home Server, or it may be a proxy. In the case of a proxy, the proxy will forward the packet, until the packet reaches the Home Server. The Home Server will record the Operator-Name and Operator-NAS- Identifier along with other information about the users session, if those attributes are present in a packet. 5.2. CoA Proxying At some later point in time, the Home Server determines that a user session should have its authorization changed, or be disconnected. The Home Server looks up the Operator-Name and Operator-NAS- Identifer, along with other user session identifiers as described in [RFC5176]. The Home Server then looks up the realm from the Operator-Name attribute in the logical AAA routing table, in order to find the "next hop" CoA server for that realm (that may be a proxy). The CoA request is then sent to that CoA server. The CoA server receives the request, and if it is a proxy, performs a similar lookup as done by the Home Server. The packet is then proxied repeatedly until it reaches the Visited Network. DeKok, Alan Proposed Standard [Page 17] INTERNET-DRAFT Dynamic Authorization Proxying in RADIUS 16 August 2018 If the proxy cannot find a destination for the request, or if no Operator-Name attribute exists in the request, the proxy will return a CoA-NAK with Error-Cause 502 (Request Not Routable). The Visited Network will receive the CoA-Request packet, and will use the Operator-NAS-Identifier (if available) attribute to determine which local CoA server (i.e. NAS) the packet should be sent to. If there is no Opertor-NAS-Identifier attribute, the Visited Network may use other means to locate the NAS, such as consulting a local database which tracks user sessions. The Operator-Name and Operator-NAS-Identifer attributes are then removed from the packet; one of NAS-IP-Address, or NAS-IPv6-Address, or NAS-Identifier is added to the packet; and the packet is then sent to the CoA server. If no CoA server can be found, the Visited Network return a CoA-NAK with Error-Cause 403 (NAS Identification Mismatch). Any response from the CoA server (NAS) is returned to the Home Network, via the normal method of returning responses to requests. 6. Security Considerations This specification incorporates by reference the Section 11 of [RFC6929]. In short, RADIUS has many known issues which are discussed in detail there, and which do not need to be repeated here. This specification adds one new attribute, and defines new behavior for RADIUS proxying. As this behavior mirrors existing RADIUS proxying, we do not believe that it introduces any new security issues. We note, however, that RADIUS proxying has a series of inherent security issues. 6.1. RADIUS Security and Proxies The requirement that packets be signed with a shared secret means that a CoA packet can only be received from a trusted party. Or transitively, received from a third party via a trusted party. This security provision of the base RADIUS protocol makes it impossible for untrusted parties to affect the user's session. When RADIUS proxying is performed, all packets are signed on a hop- by-hop basis. Any intermediate proxy can therefore forge packets, replay packets, or modify the contents of any packets entirely without detection. As a result, the secure operation of such a system depends largely on trust, instead of on technical means. DeKok, Alan Proposed Standard [Page 18] INTERNET-DRAFT Dynamic Authorization Proxying in RADIUS 16 August 2018 CoA packet proxying has all of the same issues as noted above. We note that the proxies which see and can modify CoA packets are generally the same proxies which can see or modify Access-Request and Accounting-Request packets. As such, there are few additional security implications in allowing CoA proxying. The main security implication left is that Home Networks now have the capability to disconnect, or change the authorization of users in a Visited Network. As this capability is only enabled when mutual agreement is in place, and only for those parties who can already control the users's session, 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 entire process would work exactly the same if the Operator-NAS-Identifier simply contained the NAS IP address that is hosting the user's session. The only real downside in that situation would be that external parties would see some additional private information about the Visited Network. They would still, however, be unable to leverage that information to do anything malicious. The main reason to use an opaque token for the Operator-NAS- Identifier is that there is no compelling reason to make the information public. We therefore recommend that the value be simply an opaque token. We also state that there is no requirement for integrity protection or replay detection of this attribute. The rest of the RADIUS protocol ensures that modification or replay of the Operator-NAS-Identifier will either have no effect, or will have the same effect as if the value had not been modified. Trusted parties can modify a user's session on the NAS only when they have sufficient information to identify that session. In practice, this limitation means that those parties already have access to the users's session information. Which is to say, those parties are the proxies who are already forwarding Access-Request and Accounting- Request packets. Since those parties already have the ability to see and modify all of the information about a user's session, there is no additional security issue with allowing them to 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. This limitation means that it does not matter how the values of Operator-NAS-Identifier are created, stored, or used. DeKok, Alan Proposed Standard [Page 19] INTERNET-DRAFT Dynamic Authorization Proxying in RADIUS 16 August 2018 7. IANA Considerations IANA is instructed to allocate one new RADIUS attribute, as per Section 3.3, above. The Operator-NAS-Identifier attribute is to be allocated from the RADIUS Attribute Types registry as follows: Value: [ TBD-at-Registration ] Description: Operator-NAS-Identifier Data Type: string Reference: [ RFC-to-be ] 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March, 1997, . [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000, . [RFC5080] Nelson, D., and DeKok, A., "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes", RFC 5080, December 2007, . [RFC5176] Chiba, M. et al, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 5176, January 2008, . [RFC5580] Tschofenig H., Ed. "Carrying Location Objects in RADIUS and Diameter", RFC 5580, August 2009, . [RFC6929] DeKok A. and Lior, A., "Remote Authentication Dial-In User Service (RADIUS) Protocol Extensions", RFC 6929, April 2013, . [RFC7542] DeKok A., "The Network Access Identifier", RFC 7542, May 2015, . DeKok, Alan Proposed Standard [Page 20] INTERNET-DRAFT Dynamic Authorization Proxying in RADIUS 16 August 2018 [RFC8044] DeKok A., "Data Types in the Remote Authentication Dial-In User Service Protocol (RADIUS)", RFC 8044, January 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", RFC 8174, May 2017, . 8.2. Informative References [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000, . Authors' Addresses Alan DeKok The FreeRADIUS Server Project Email: aland@freeradius.org Jouni Korhonen EMail: jouni.nospam@gmail.com DeKok, Alan Proposed Standard [Page 21]