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

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/