wdiff rfc8559.original rfc8559.txt

.nr HY 0

Network Working Group DeKok, Alan
INTERNET-DRAFT
Internet Engineering Task Force (IETF) A. DeKok
Request for Comments: 8559 FreeRADIUS
Updates: 5176, 5580 J. Korhonen
Category: Standards Track
<draft-ietf-radext-coa-proxy-10.txt>
22 January April 2019
ISSN: 2070-1721

Dynamic Authorization Proxying in the Remote Authorization Authentication
Dial-In User Service Protocol (RADIUS)
draft-ietf-radext-coa-proxy-10.txt Protocol

Abstract

RFC 5176 defines Change of Authorization Change-of-Authorization (CoA) and Disconnect Message
(DM) behavior for RADIUS. That document RFC 5176 also suggests that proxying these
messages is possible, but gives no it does not provide guidance as to how it that
is done. This specification updates RFC 5176 to correct that
omission for scenarios where networks use Realm-based realm-based proxying as
defined in RFC 7542. This specification also updates RFC 5580 to
allow the Operator-Name attribute in CoA-Request and Disconnect-Request Disconnect-
Request packets.

Status of this 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 an Internet Standards Track document.

This document is a product 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
(IETF). It represents the consensus of six months the IETF community. It has
received public review and may be updated, replaced, or obsoleted has been approved for publication by other documents at any
time. It the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work available in progress."

The list Section 2 of RFC 7841.

Information about the current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list status of Internet-Draft Shadow Directories can this document, any errata,
and how to provide feedback on it may be accessed obtained at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on July 22, 2019.
https://www.rfc-editor.org/info/rfc8559.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info/)
(https://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.

Table of Contents

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

1. Introduction

RFC 5176 [RFC5176] defines Change of Authorization 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 it
does not provide guidance as to how that is done. This omission
means that in practice, proxying of CoA packets is impossible.

We partially correct that ommission omission 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 home network to a
Visited Network. visited network. We
then introduce a new attribute; Operator-NAS-
Identifier. attribute: Operator-NAS-Identifier. This
attribute permits packets to be routed from the RADIUS server at the Visited Network
visited network to the NAS. Network Access Server (NAS).

This correction is limited to the use-case use case of Realm-based realm-based proxying as
defined in [RFC7542]. Other forms of proxying are possible, possible but are
not discussed here. We note that the recommendations of provided in
this document apply only to those systems which that implement proxying of
CoA packets, and then only to those that implement Realm-based realm-based CoA
proxying. This specification neither requires nor suggests changes
to any implementation or deployment of any other RADIUS systems.

We also update the behavior of described in [RFC5580] to allow the
Operator-Name attribute to be used in CoA-Request and Disconnect-Request Disconnect-
Request packets, as further described in this document.

This document is a Proposed Standard Standards Track document in order to update the
behavior
of described in [RFC5580], which as [RFC5580] is also a Proposed Standard. Standards
Track document. This document relies heavily upon and also updates
some behavior of the behaviors described in RFC 5176, which is an
Informational document; though because the applicability statements in
Section 1.1 of [RFC5176] do not apply to this document, this document
does not change the status of [RFC5176].

We finally conclude with a discussion of the security implications of
this design, 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. authorization, e.g., CoA-Request, or CoA-ACK, or CoA-NAK,
as defined in [RFC5176]. That specification [RFC5176] also defines
Disconnect-Request, Disconnect-
Request, Disconnect-ACK, and Disconnect-NAK. For
simplicity here, simplicity,
where we use "CoA", "CoA" in this document, we mean a generic "CoA-
Request
"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

The user identity submitted by the client during network access
authentication. See [RFC7542]. 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 application-layer authentication.

Network Access Server

The Network Access Server (NAS) is the

The device that clients connect to in order to get access to the
network. In Point to Point 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 that 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 visited network typically has a
relationship with the Home Network, 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.

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) an 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, possible but are not discussed
here.

In order to determine the "next hop" for a packet, the proxying
server looks up the "Realm" "realm" portion of the NAI in a logical AAA
Authentication, Authorization, and Accounting (AAA) routing table, as
described in Section 3 of [RFC7542]. The entry in that table
contains information about the "next hop" next hop to which the packet is sent.
This information can be IP address, shared secret, certificate, etc.
The "next hop" next hop may also be another proxy, or it may be the Home Server home server
for that realm.

If the "next hop" next hop is a proxy, that proxy will perform the same Realm
lookup, realm
lookup and then proxy the packet as above. At some point, the "next
hop"
next hop will be the Home Server home server for that realm.

The Home Server home server validates the NAI in the User-Name attribute against
the list of Realms realms hosted by the Home Network. 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 continues until the
response packet arrives at the NAS.

The proxies are typically stateful with respect to ongoing request /
response packets,
request/response packets but are 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
Proxying both Access-Request and Accounting-Request packets allows
proxies to connect Visited
Networks visited networks to Home Networks home networks for all AAA
purposes.

2.2. CoA Processing

[RFC5176] describes how CoA clients send packets to CoA servers. We
note that a 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, with or is the same as, 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 [RFC5176] does
not make any suggestions for as to 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, session and then to
proxy the CoA packet to the RADIUS client that originated the Access-
Request
Access-Request for that session. There are many problems with such a
scenario.

The CoA server may, might not, in fact, not be co-located with the RADIUS
client. In
client, in which case it may might 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
that 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 failover 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.

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 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. 4.1 of [RFC5580]. 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

...followed a few paragraphs later 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 realm of the Visited Network. e.g. visited network. For example, 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 the
following:

o how the forward path has to change in order to allow reverse path proxying.
We then describe
proxying

o how reverse path proxying works. And we describe works

o how Visited Networks visited networks and Home Networks home networks have to behave in order for
CoA proxying to work. work

We note that as a proxied CoA packet is sent only to only one destination,
the Operator-Name attribute MUST NOT occur more than once in a
packet. If a packet contains more than one Operator-Name,
implementations MUST treat the second and subsequent attributes as
"invalid attributes", as discussed in Section 2.8 of [RFC6929].

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

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

Visited Networks networks MUST use a consistent value for Operator-Name for
any one user session. That is, sending "1example.com" in an Access-
Request packet,
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, 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 networks SHOULD record Operator-Name along with any other
information that they record about user sessions. Home Networks networks that
expect to send CoA packets to Visited Networks visited networks MUST record Operator-
Name
Operator-Name for each user session that originates from a Visited Network. visited
network. Failure to record the Operator-Name would mean that the Home Network home
network would not know where to send any CoA packet. packets.

Networks that host both the RADIUS client and RADIUS server do not
need to create, record record, or track Operator-Name. That is, if the
Visited Network
visited network and Home Network 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 Packets

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

The Home Network home network MUST lookup look up the realm from the Operator-Name
attribute in a logical "realm routing table", as discussed in [RFC7542]
Section 3. 3 of [RFC7542]. That logical realm table is defined there
therein 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" next-hop
CoA servers.

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

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, 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 attribute in a logical "realm routing table", as with Home
Servers,
home servers, above. The packet is then sent to the proxy for the
realm
which that was found in that table. This process continues with any
subsequent proxies until the packet reaches a public CoA server at
the Visited Network. visited network.

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

Proxies which that receive a CoA packet MUST NOT use the NAI from the
User-Name attribute in order to make proxying decisions. Doing so
would result in the CoA packet being forwarded to the Home Network, home network,
while the user's session is in the Visited Network. visited network.

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

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

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

Some Home Networks home networks will not have permission to send CoA packets to
the Visited Network. visited network. The CoA server SHOULD therefore also validate
the NAI contained in the User-Name attribute. If the Home Network home network is
not permitted to send CoA packets to this Visited Network, visited network, then the
CoA server MUST return a NAK packet that contains an Error-Cause
attribute
Attribute having value 502 ("Request Not Routable").

These checks make it more difficult for a malicious Home Network home network to
scan roaming network networks in order to determine which Visited Network visited network
hosts which Realm. realm. That information should be known to all parties
in advance, advance and exchanged via methods outside the scope of this
specification. Those methods will typically be in the form of
contractual relationships between parties, parties or as membership in a roaming
consortium.

The CoA server in the Visited Network 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 Attribute having value 403 ("NAS
Identification Mismatch").

All other received packets are processed as per local site rules, 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 (described above).

Processing done by Visited Network the visited network will normally include sending
the CoA packet to the NAS; NAS, having the NAS process it; it, and then
returning any response packet packets back up the proxy chain to the Home Server. home
server.

The only missing piece here is the procedure by which the Visited
Network visited
network gets the packet from its public CoA server to the NAS. The
Visited Network
visited network could use NAS-Identifier, NAS-IP-Address, or NAS-
IPv6-Address,
NAS-IPv6-Address, but these attributes may have been edited by an
intermediate proxy, proxy or the attributes may be missing entirely.

These attributes may be incorrect because proxies forwarding Access-
Request
Access-Request packets often re-write rewrite them for internal policy
reasons. These attributes may be missing, because the Visited Network visited
network may not want all upstream proxies and Home Servers home servers to have
detailed information about the internals of its private network, network and
may remove them itself.

We therefore need a way to identify a NAS in the Visited Network, in visited network via
a way which is both private, method that affords privacy and which does not use any existing
attribute.
attributes. Our solution is to define an Operator-NAS-Identifier
attribute, which identifies an individual NAS in the Visited Network. 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. visited network. It MAY appear in
the following packets: Access-Request, Accounting-Request, CoA-
Request,
CoA-Request, or Disconnect-Request. Operator-NAS-Identifier MUST NOT
appear in any other packet. packets.

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. As each proxied CoA packet is sent only to only one NAS, the Operator-NAS-
Identifier
Operator-NAS-Identifier attribute MUST NOT occur more than once in a
packet. If a packet contains more than one Operator-NAS-Identifier,
implementations MUST treat the second and subsequent attributes as
"invalid attributes", as discussed in Section 2.8 of [RFC6929].

An Operator-NAS-Identifer Operator-NAS-Identifier attribute SHOULD be added to an Access-
Request
Access-Request or Accounting-Request packet by a Visited Network, visited network,
before proxying a packet to an external RADIUS server. When the Operator-
NAS-Identifer
Operator-NAS-Identifier attribute is added to a packet, the following
attributes SHOULD be deleted from the packet: NAS-IP-Address, NAS-
IPv6-Address,
NAS-IPv6-Address, and NAS-Identifier. If these attributes are
deleted, the proxy MUST then add a new NAS-Identifier attribute,
in order to satisfy the requirements of Section 4.1 of [RFC2865], [RFC2865] and
Section 4.1 of [RFC2866]. The contents of the new NAS-Identifier
attribute SHOULD be the
Realm realm name of the visited network.

When a server receives a packet that already contains an Operator-
NAS-Identifer
NAS-Identifier attribute, no such editing is performed.

The Operator-NAS-Attribute Operator-NAS-Identifier attribute MUST NOT be added to any packet
by any other proxy or server in the network. Only the Visited Network (i.e. visited
network (i.e., the operator) can name a NAS which that is inside of the Visited Network.
visited network.

The result of these requirements is that for everyone outside of the
Visited Network,
visited network there is only one NAS: the Visited Network visited network itself.
And,
Also, the Visited Network 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 as defined in Section 4.1 of [RFC5580].

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

Description

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

Type

TBD. To be assigned

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

Length

4 to 35.

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

Data Type

string.

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

Value

The contents of this

This attribute are contains an opaque token interpretable that can only be
interpreted by the Visited Network. visited network.

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

The first method is to create an opaque token per NAS, 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; 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
locally known information can be used to un-obfuscate unobfuscate 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 Media Access Control (MAC) address of the NAS.
There is therefore no requirement that Operator-NAS-Identifier obsfuscate
obfuscate or hide in any way the total number of NASes in a Visited Network.
visited network. That information is already public knowledge.

4. Requirements

4.1. Requirements on Home Servers

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

A Home Server 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 visited network that receives a CoA packet that will be proxied to
a NAS MUST perform all of the operations required for proxies by proxies; see
Section 4.3.2. This We specify this requirement is because we assume that
the
Visited Network visited network has a proxy in between the NAS and any external (i.e.
(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 visited network uses the content contents of the Operator-NAS-Identifier
attribute to determine which NAS will receive the packet.

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

The Visited Network 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,
NAS-IPv6-Address, or NAS-Identifier. This step is the inverse of the
removal suggested above in Section 3.4.

In general, the NAS should only receive attributes which that identify or
modify a user's session. It is not appropriate to send to a NAS
attributes which that 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, proxy
and that the two systems can communicate electronically. There is no
requirement for that these systems to be co-located.

4.3.1. Security Requirements on Proxies

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

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

We strengthen that requirement by saying that a proxy MUST perform a
"reverse
reverse path forwarding" (RPF) forwarding check to verify that a CoA packet originates
from an authorized Dynamic Authorization Client. Without this check,
a proxy may forward packets from misconfigured or malicious parties, 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 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 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

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

We suggest that the real-world effect of this security problem is
minimal. RADIUS proxies can already return Access-Accept or Access-
Reject
Access-Reject for Access-Request packets, 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. authentication.

The largest biggest problem is that there are no provisions in RADIUS for
"end to end"
"end-to-end" security. That is, the Visited Network visited network and Home Network 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.

We cannot therefore cannot prevent proxies or Home Servers 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

This requirement is too stringent for a CoA proxy. Only the final
CoA server (i.e (i.e., NAS) can make a decision on decide which attributes are mandatory and
which are not.

Instead, we say that for in the case of a CoA proxy, we say that all attributes
MUST NOT be treated as mandatory. Proxies implementing this
specification MUST perform proxying based on Operator-Name. Other
schemes are possible, possible but are not discussed here. Proxies SHOULD
forward all packets as-
is, either "as is" or 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 [RFC5176] as follows: in CoA-Request and
Disconnect-Request packets, the NAS MUST NOT treat as mandatory any
attribute which that is known to not affect the users session. For user's 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-Name 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 proxies 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
visited network to the Home Network Network home network MUST be removed by the
corresponding CoA proxy from packets traversing the reverse path.
That is, any attribute editing of attributes that is done on the "forward" path
MUST be undone on the "reverse" path.

The result is that a NAS will only ever receive CoA packets that
either contain (1) attributes sent by the NAS to it's its local RADIUS
server,
server or contain (2) attributes that are sent by the Home Server 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, 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. visited network. The login attempt is done via a NAS in
the
Visited Network. 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, roaming and will add an Operator-Name attribute, with
value "1" followed by it's its own realm name. e.g. name, e.g., "1example.com". The
visited RADIUS server MAY also add an Operator-NAS-Identifier. Operator-NAS-Identifier
attribute. The NAS identification attributes are also edited, as
required by Section 3.4, above.

The Visited Server visited server will then proxy the authentication request to an
upstream server. That server may be the Home Server, home server, or it may be a
proxy. In the case of a proxy, the proxy will forward the packet, packet
until the packet reaches the Home Server. home server.

The Home Server home server will record the Operator-Name and Operator-NAS-
Identifier attributes, along with other information about the users user's
session, if those attributes are present in a packet.

5.2. CoA Proxying

At some later point in time, the Home Server home server determines that
(1) a user session should have its authorization changed, changed or
(2) the user should be disconnected. The Home Server home server looks up the
Operator-Name and Operator-NAS-
Identifer, Operator-NAS-Identifier attributes, along with
other user session identifiers as described in [RFC5176]. The Home Server 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" next-hop CoA
server for that realm (that (which may be a proxy). The CoA request CoA-Request is
then sent to that CoA server.

The CoA server receives the request, and request and, if it is a proxy, performs a
lookup similar to the lookup as done by the Home Server. home server. The packet is
then proxied repeatedly until it reaches the Visited Network. visited network.

If the proxy cannot find a destination for the request, request or if no
Operator-Name attribute exists in the request, the proxy will return
a CoA-NAK with Error-Cause 502 (Request ("Request Not Routable). Routable").

The Visited Network visited network will receive the CoA-Request packet, packet and will use
the Operator-NAS-Identifier attribute (if available) attribute to determine
which local CoA server (i.e. (i.e., NAS) the packet should be sent to. If
there is no Opertor-NAS-Identifier Operator-NAS-Identifier attribute, the Visited Network visited network
may use other means to locate the NAS, such as consulting a local
database which that tracks user sessions.

The Operator-Name and Operator-NAS-Identifer Operator-NAS-Identifier 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 visited network returns a CoA-NAK
with Error-Cause 403 (NAS ("NAS Identification Mismatch). Mismatch").

Any response from the CoA server (NAS) is returned to the Home
Network, 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; those issues which are discussed in
detail there, in [RFC6929] and which do not need to be repeated here.

This specification adds one new attribute, 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 many 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 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
hop-by-hop basis. Any intermediate proxy can therefore forge
packets, replay packets, or modify the contents of any packet. Any
system receiving correctly signed packets entirely
without detection. must accept them at face
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,
trust instead of on technical means.

CoA packet proxying has all of the same issues as those noted above.
We note that the proxies which that see and can modify CoA packets are
generally the same proxies which that 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 that remains is that Home Networks home networks now
have the
capability ability to disconnect, disconnect or change the authorization of users
in a
Visited Network. 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, user sessions, 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 attribute 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. 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 attribute 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 attribute will either have no effect, 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
user's session information. Which is to say, In other words, 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.

7. IANA Considerations

Per Section 3.4 of this document, IANA is instructed to allocate has allocated one new RADIUS attribute, as per
Section 3.3, above. The Operator-NAS-Identifier
attribute is to be
allocated (the Operator-NAS-Identifier attribute) from the RADIUS "short
extended space" of the "RADIUS Attribute Types Types" registry as follows:

Value: [ TBD-at-Registration ] 241.8
Description: Operator-NAS-Identifier
Data Type: string
Reference: [ RFC-to-be ] RFC 8559

8. References

8.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March,
DOI 10.17487/RFC2119, March 1997, <http://www.rfc-edi-
tor.org/info/rfc2119>.
<https://www.rfc-editor.org/info/rfc2119>.

[RFC2865] Rigney, C., Willens, S., Rubens, A. A., and W. Simpson,
"Remote Authen-
tication Authentication Dial In User Service (RADIUS)",
RFC 2865, DOI 10.17487/RFC2865, June 2000,
<http://www.rfc-editor.org/info/rfc2865>.
<https://www.rfc-editor.org/info/rfc2865>.

[RFC5080] Nelson, D., D. and A. DeKok, A., "Common Remote Authentication
Dial In User Service (RADIUS) Implementation Issues and
Suggested Fixes", RFC 5080, DOI 10.17487/RFC5080,
December 2007, <http://www.rfc-editor.org/info/rfc5080>. <https://www.rfc-editor.org/info/rfc5080>.

[RFC5176] Chiba, M. et al, M., Dommety, G., Eklund, M., Mitton, D., and B.
Aboba, "Dynamic Authorization Extensions to Remote
Authentication Dial In User Service (RADIUS)", RFC 5176,
DOI 10.17487/RFC5176, January 2008, <http://www.rfc-editor.org/info/rfc5176>.
<https://www.rfc-editor.org/info/rfc5176>.

[RFC5580]
Tschofenig Tschofenig, H., Ed. Ed., Adrangi, F., Jones, M., Lior, A., and
B. Aboba, "Carrying Location Objects in RADIUS and Diame-
ter",
Diameter", RFC 5580, DOI 10.17487/RFC5580, August 2009, <http://www.rfc-edi-
tor.org/info/rfc5580>.
<https://www.rfc-editor.org/info/rfc5580>.

[RFC6929]
DeKok DeKok, A. and A. Lior, A., "Remote Authentication Dial-In Dial In User
Service (RADIUS) Protocol Extensions", RFC 6929,
DOI 10.17487/RFC6929, April 2013,
<http://www.rfc-editor.org/info/rfc6929>.
<https://www.rfc-editor.org/info/rfc6929>.

[RFC7542]
DeKok DeKok, A., "The Network Access Identifier", RFC 7542,
DOI 10.17487/RFC7542, May 2015,
<http://www.rfc-editor.org/info/rfc7542>.
<https://www.rfc-editor.org/info/rfc7542>.

[RFC8044]
DeKok DeKok, A., "Data Types in the Remote Authentication Dial-In User
Service Protocol (RADIUS)", RADIUS", RFC 8044,
DOI 10.17487/RFC8044, January 2017,
<http://www.rfc-editor.org/info/rfc8044>.
<https://www.rfc-editor.org/info/rfc8044>.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in
RFC 2119 Key Words", BCP 14, RFC 8174,
DOI 10.17487/RFC8174, May 2017, <http://www.rfc-edi-
tor.org/info/rfc8174>.
<https://www.rfc-editor.org/info/rfc8174>.

8.2. Informative References

[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866,
DOI 10.17487/RFC2866, June 2000,
<http://www.rfc-editor.org/info/rfc2866>.
<https://www.rfc-editor.org/info/rfc2866>.

Authors' Addresses

Alan DeKok
The FreeRADIUS Server Project

Email: aland@freeradius.org

Jouni Korhonen

EMail:

Email: jouni.nospam@gmail.com