draft-ietf-radext-coa-proxy-04.txt   draft-ietf-radext-coa-proxy-05.txt 
Network Working Group DeKok, Alan Network Working Group DeKok, Alan
INTERNET-DRAFT FreeRADIUS INTERNET-DRAFT FreeRADIUS
Updates: 5176 J. Korhonen Updates: 5176 J. Korhonen
Category: Standards Track Nokia Siemens Networks Category: Standards Track
<draft-ietf-radext-coa-proxy-04.txt> <draft-ietf-radext-coa-proxy-05.txt>
24 April 2018 30 July 2018
Dynamic Authorization Proxying in Dynamic Authorization Proxying in
Remote Authorization Dial-In User Service Protocol (RADIUS) Remote Authorization Dial-In User Service Protocol (RADIUS)
draft-ietf-radext-coa-proxy-04.txt draft-ietf-radext-coa-proxy-05.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. Section 3.1 of that document suggests that (DM) behavior for RADIUS. Section 3.1 of that document suggests that
proxying these messages is possible, but gives no guidance as to how proxying these messages is possible, but gives no guidance as to how
that is done. This specification corrects that omission for that is done. This specification corrects that omission for
scenarios where networks use Realm-based proxying as defined in scenarios where networks use Realm-based proxying as defined in
[RFC7542]. [RFC7542].
skipping to change at page 1, line 44 skipping to change at page 1, line 44
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 24, 2018. This Internet-Draft will expire on January 30, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 (http://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
skipping to change at page 3, line 26 skipping to change at page 3, line 26
3.2. Proxying of CoA-Request and Disconnect-Request packet 8 3.2. Proxying of CoA-Request and Disconnect-Request packet 8
3.3. Operator-NAS-Identifier ............................. 9 3.3. Operator-NAS-Identifier ............................. 9
4. Requirements ............................................. 11 4. Requirements ............................................. 11
4.1. Requirements on Home Servers ........................ 11 4.1. Requirements on Home Servers ........................ 11
4.2. Requirements on Visited Networks .................... 11 4.2. Requirements on Visited Networks .................... 11
4.3. Requirements on Proxies ............................. 12 4.3. Requirements on Proxies ............................. 12
4.3.1. Security Requirements on Proxies ............... 12 4.3.1. Security Requirements on Proxies ............... 12
4.3.2. Filtering Requirements on Proxies .............. 13 4.3.2. Filtering Requirements on Proxies .............. 13
5. Functionality ............................................ 14 5. Functionality ............................................ 14
5.1. User Login .......................................... 14 5.1. User Login .......................................... 14
5.2. CoA Proxing ......................................... 14 5.2. CoA Proxying ........................................ 14
6. Security Considerations .................................. 15 6. Security Considerations .................................. 15
7. IANA Considerations ...................................... 15 7. IANA Considerations ...................................... 15
8. References ............................................... 15 8. References ............................................... 15
8.1. Normative References ................................ 15 8.1. Normative References ................................ 15
8.2. Informative References .............................. 16 8.2. Informative References .............................. 16
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 that Disconnect Message (DM) behavior for RADIUS. Section 3.1 of that
document suggests that proxying these messages is possible, but gives document suggests that proxying these messages is possible, but gives
no guidance as to how that is done. This omission means that in no guidance as to how that is done. This omission means that in
practice, proxying of CoA packets is impossible. practice, proxying of CoA packets is impossible.
We correct that ommission here by explaining how proxying of these We partially correct that ommission here by explaining how proxying
packets can be done by leveraging an existing RADIUS attribute, of these packets can be done by leveraging an existing RADIUS
Operator-Name (Section 4.1 of [RFC5580]). We then explain how this attribute, Operator-Name (Section 4.1 of [RFC5580]). We then explain
attribute can be used by CoA proxies to route packets "backwards" how this attribute can be used by CoA proxies to route packets
through a RADIUS proxy chain to the Visited Network. We introduce a "backwards" through a RADIUS proxy chain to the Visited Network. We
new attribute; Operator-NAS-Identifier, which permits packets to be introduce a new attribute; Operator-NAS-Identifier, which permits
routed from the RADIUS server at the Visited Network to the NAS. We packets to be routed from the RADIUS server at the Visited Network to
then explain how use of this attribute can increase privacy of the the NAS. We then explain how use of this attribute can increase
internal implementation of the visited network. privacy of the internal implementation of the visited network.
We limit the use-case of CoA proxying to Realm-based proxying as This correction is limited to the use-case of CoA proxying to Realm-
defined in [RFC7542]. Other forms of CoA proxying are possible, but based proxying as defined in [RFC7542]. Other forms of CoA proxying
are not specified here. are possible, but are not specified here.
We conclude with a discussion of the security implications of the We conclude with a discussion of the security implications of the
design, and show how they are acceptable. design, and show how they are acceptable.
1.1. Terminology 1.1. Terminology
This document frequently uses the following terms: This document frequently uses the following terms:
CoA CoA
skipping to change at page 5, line 28 skipping to change at page 5, line 28
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", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "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 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 RFC 5176 is insufficient work, and why CoA proxying as discussed in RFC 5176 is insufficient
in practice. in practice.
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
skipping to change at page 6, line 32 skipping to change at page 6, line 32
"next hop" may be another proxy, or it may be the home server for "next hop" may be another proxy, or it may be the home server for
that realm. that realm.
If the "next hop" is a proxy, it will perform the same Realm lookup, If the "next hop" is a proxy, it will perform the same Realm lookup,
and then proxy the packet. Alternatively, if the "next hop" is the and then proxy the packet. Alternatively, if the "next hop" is the
Home Server for that realm, it will try to authenticate the user, and Home Server for that realm, it will try to authenticate the user, and
respond with an Access-Accept, Access-Reject, or Access-Challenge. respond with an Access-Accept, Access-Reject, or Access-Challenge.
The RADIUS client will match the response packet to an outstanding The RADIUS client will match the response packet to an outstanding
request. If the client is part of a proxy, it will then proxy that request. If the client is part of a proxy, it will then proxy that
response packet in turn to the system which originated the Access- response packet in turn to the system that originated the Access-
Request. This process occurs until the response packet arrives at Request. This process occurs until the response packet arrives at
the NAS. the NAS.
The proxies are typically stateful with respect to ongoing request / The proxies are typically stateful with respect to ongoing request /
response packets, but stateless with respect to user sessions. Once response packets, but stateless with respect to user sessions. Once
a response has been received by the proxy, it can discard all a response has been received by the proxy, it can discard all
information about the request packet. information about the request packet.
The same proxy method is used for Accounting-Request packets. The The same proxy method is used for Accounting-Request packets. The
combination of the two methods allows proxies to connect Visited combination of the two methods allows proxies to connect Visited
skipping to change at page 7, line 18 skipping to change at page 7, line 18
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 multiple networks are The situation is more complicated when multiple networks are
involved. [RFC5176] suggests that CoA proxying is permitted, but involved. [RFC5176] suggests that CoA proxying is permitted, but
makes no suggestions for how it should be done. makes no suggestions for how it should be done.
If proxies tracked user sessions, it might be possible for a proxy to If proxies tracked user sessions, it might be possible for a proxy to
match an incoming CoA-Request to a user session, and then to proxy match an incoming CoA-Request to a user session, and then to proxy
that packet to the RADIUS client which originated the Access-Request that packet to the RADIUS client that originated the Access-Request
for that sessions. for that sessions.
There are many problems with such a scenario. The CoA server may, in There are many problems with such a scenario. The CoA server may, in
fact, not be co-located with the RADIUS client. The RADIUS client fact, not be co-located with the RADIUS client. The RADIUS client
may be down, but there may be a different CoA server which could may be down, but there may be a different CoA server which could
accept the packet. User session tracking can be expensive and successfully process the packet. User session tracking can be
complicated for a proxy, and many proxies do not record user expensive and complicated for a proxy, and many proxies do not record
sessions. Finally, [RFC5176] is silent on the topic of "session user sessions. Finally, [RFC5176] is silent on the topic of what
identification attributes", which makes it impossible for a proxy to attributes constitute "session identification attributes", which
determine if a CoA packet matches a particular user session. makes it 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 cannot be The result of all of these issues is that CoA proxying cannot be
performed when using the behavior defined in [RFC5176]. performed 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 the Operator-Name The solution to the above problem is to use the Operator-Name
attribute defined in [RFC5580], Section 4.1. We repeat a portion of attribute defined in [RFC5580], Section 4.1. We repeat a portion of
that definition here for clarity: that definition here for clarity:
skipping to change at page 8, line 25 skipping to change at page 8, line 25
Name attribute in the packet, as discussed in Section 4.1 of Name attribute in the packet, as discussed in Section 4.1 of
[RFC5580]. The contents of the Operator-Name should be "1", followed [RFC5580]. The contents of the Operator-Name should be "1", followed
by the realm name of the Visited Network. Where the Visited Network by the realm name of the Visited Network. Where the Visited Network
has more than one realm name, a "canonical" one should be chosen, and has more than one realm name, a "canonical" one 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
one user session. That is, sending "1example.com" in an Access- one user session. That is, sending "1example.com" in an Access-
Request packet, and "1example.org" in an Accounting-Request packet Request packet, and "1example.org" in an Accounting-Request packet
for that same session is forbidden. Such behavior would make it look for that same session is forbidden. Such behavior would make it look
like the users session was simultaneously in two different Visited like a single user session was activee simultaneously in two
Networks, which is impossible. different Visited Networks, which is impossible.
Proxies which record user session information SHOULD also record Proxies that record user session information SHOULD also record
Operator-Name. Proxies which 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 information that they record about user sessions. Home Networks that
which expect to send CoA packets to Visited Networks MUST record expect to send CoA packets to Visited Networks MUST record Operator-
Operator-Name for each user session which originates from a Visited Name for each user session that originates from a Visited Network.
Network. Failure to record the Operator-Name would mean that it Failure to record the Operator-Name would mean that the Home Network
would be impossible to send CoA packets to the Visited Network. would not know where to send any CoA packet.
Networks which contain both the RADIUS client and RADIUS server do Networks that contain both the RADIUS client and RADIUS server do not
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 packet. The value of the Operator-Name MUST be the attribute in the packet. The value of the Operator-Name MUST be the
value which was recorded earlier for that user session. value which was recorded earlier for that user session.
The Home Network MUST lookup the realm from the Operator-Name in a The Home Network MUST lookup the realm from the Operator-Name in a
logical "realm routing table", as discussed in [RFC7542] Section 3. logical "realm routing table", as discussed in [RFC7542] Section 3.
That logical realm table is defined there as: That logical realm table is defined there 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 ore 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 realm from the User-Name attribute. the realm from the User-Name attribute.
Proxies which receive the CoA packet MUST look up the realm from the Proxies that receive the CoA packet MUST look up the realm from the
Operator-Name in a logical "realm routing table", as with Home Operator-Name in a logical "realm routing table", as with Home
Servers, above. The packet is then sent to the realm which was found Servers, above. The packet is then sent to the realm which was found
in that table. This process continues with any subsequent proxies in that table. This process continues with any subsequent proxies
until the packet reaches the Visited Network. until the packet reaches the Visited Network.
The Visited Network can then send the CoA packet to the NAS, and The Visited Network can then send the CoA packet to the NAS, and
return any response packet back up the proxy chain to the Home return any response packet back up the proxy chain to the Home
Server. Server.
The only missing piece here is how the Visited Network gets the The only missing piece here is how the Visited Network gets the
packet from its CoA server to the NAS. The Visited Network could use packet from its CoA server to the NAS. The Visited Network could use
NAS-Identifier, NAS-IP-Address, or NAS-IPv6-Address, but these NAS-Identifier, NAS-IP-Address, or NAS-IPv6-Address, but these
attributes may be incorrect, or may be missing entirely. attributes may be incorrect, or may be missing entirely.
These attributes may be incorrect because proxies which forward These attributes may be incorrect because proxies that forward
Access-Request packets often re-write them for internal policy Access-Request packets often re-write them for internal policy
reasons. These attributes may be missing, because the Visited reasons. These attributes may be missing, because the Visited
Network may not want all upstream proxies and Home Servers to have Network may not want all upstream proxies and Home Servers to have
detailed information about the internals of its private network. detailed information about the internals of its private network.
We therefore need a way to identifier a NAS in the Visited Network, We therefore need a way to identifier a NAS in the Visited Network,
in a way which is both private, and which does not use any existing in a way which is both private, and which does not use any existing
attribute. attribute.
3.3. Operator-NAS-Identifier 3.3. Operator-NAS-Identifier
The Operator-NAS-Identifier attribute contains opaque information The Operator-NAS-Identifier attribute contains opaque information
which identifies a NAS in a Visited Network. It MAY appear in the that identifies a NAS in a Visited Network. It MAY appear in the
following packets: Access-Request, Accounting-Request, CoA-Request, following packets: Access-Request, Accounting-Request, CoA-Request,
or Disconnect-Request. Operator-NAS-Identifier MUST NOT appear in or Disconnect-Request. Operator-NAS-Identifier MUST NOT appear in
any other packet. any other packet.
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 MUST
NOT appear in a packet if there is no Operator-Name in the packet. NOT appear in a packet if there is no Operator-Name in the packet.
Operator-NAS-Identifier MUST NOT occur more than once in a packet. Operator-NAS-Identifier MUST NOT occur more than once in a packet.
An Operator-NAS-Identifer attribute SHOULD be added to an Access- An Operator-NAS-Identifer attribute SHOULD be added to an Access-
Request or Accounting-Request packet by a Visited Network just before Request or Accounting-Request packet by a Visited Network just before
proxying a packet to an external RADIUS server. When the Operator- proxying a packet to an external RADIUS server. When the Operator-
NAS-Identifer attribute is added to a packet, the following NAS-Identifer attribute is added to a packet, the following
attributes MUST be deleted: NAS-IP-Address, NAS-IPv6-Address, NAS- attributes MUST be deleted: NAS-IP-Address, NAS-IPv6-Address, NAS-
Identifier. The proxy MUST then add a NAS-Identifier attribute, in Identifier. The proxy MUST then add a NAS-Identifier attribute, in
order satisfy the requirements of Section 4.1 of [RFC2865], and of order satisfy the requirements of Section 4.1 of [RFC2865], and
[RFC2866]. Section 4.1 of [RFC2866]. When a server receives a packet that
already contains an Operator-NAS-Identifer attribute, no such editing
is performed.
The Operator-NAS-Identifier attribute parallels the Operator-Name
attribute that was defined in Section 4.1 of [RFC5580].
We suggest that the contents of the NAS-Identifier be the Realm name We suggest that the contents of the NAS-Identifier be the Realm name
of the Visited Network. That is, for everyone outside of the Visited of the Visited Network. That is, for everyone outside of the Visited
Network, there is only one NAS: the Visited Network itself. For the Network, there is only one NAS: the Visited Network itself. For the
Visited Network, the identity of the NAS is private information, Visited Network, the identity of the NAS is private information,
which is opaque to everyone else. which is opaque to everyone else.
The new 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". TBD. To be assigned by IANA from the "short extended space".
Length Length
skipping to change at page 11, line 4 skipping to change at page 11, line 11
creating an Operator-NAS-Identifier MUST NOT create attributes creating an Operator-NAS-Identifier MUST NOT create attributes
with more than twenty octets of data. A twenty octet string is with more than twenty octets of data. A twenty octet string is
more than sufficient to individually address all of the NASes on more than sufficient to individually address all of the NASes on
the planet. the planet.
Data Type Data Type
string. See [RFC8044] Section 3.6 for a definition. string. See [RFC8044] Section 3.6 for a definition.
Value Value
The contents of this attribute are an opaque token interpretable The contents of this attribute are an opaque token interpretable
only by the Visited Network. only 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 users session. In practice, this requirement the NAS for the users session. In practice, this requirement
means that the Visited Network will either track these tokens in a means that for non-trivial use-cases, the Visited Network will
database, or it will create tokens which can be decoded in order either track these tokens in a database, or it will create tokens
to reveal the identity of the NAS. that can be decoded in order to reveal the identity of the NAS.
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 any a CoA packet for a user session, the Home Server MUST include any
Operator-NAS-Identifier it has recorded for that session. Operator-NAS-Identifier it has recorded for that 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 provisions of the next few sections describe how other The provisions of the next few sections describe how other
participants in the RADIUS ecosystem can enforce this requirement. participants in the RADIUS ecosystem can enforce this requirement.
4.2. Requirements on Visited Networks 4.2. Requirements on Visited Networks
A Visited Network which receives a proxied CoA packet MUST perform A Visited Network which receives a CoA packet that will be proxied
all of the checks discussed above for proxies. This requirement is MUST perform all of the operations required for proxies by Section
because we assume that the Visited Network has a proxy in between the 4.3.2. This requirement is because we assume that the Visited
NAS and any external (i.e. third-party) proxy. Situations where a Network has a proxy in between the NAS and any external (i.e. third-
NAS sends packets directly to a third-party RADIUS server are outside party) proxy. Situations where a NAS sends packets directly to a
of the scope of this specification. third-party RADIUS server are outside of the scope of this
specification.
Due to the limited number of attributes allowed in CoA packets by Due to the limited number of attributes allowed in CoA packets by
[RFC5176] Section 2.3, a Visited Network MUST remove the Operator- [RFC5176] Section 2.3, a Visited Network MUST remove the Operator-
Name and Operator-NAS-Identifier attributes from any CoA-Request or Name and Operator-NAS-Identifier attributes from any CoA-Request or
Disconnect-Request packet prior to proxying that packet to the final Disconnect-Request packet prior to proxying that packet to the final
CoA server (i.e. NAS). This requirement is phrase more generically CoA server (i.e. NAS). This requirement is phrase more generically
below, in Section 4.3.2. below, in Section 4.3.2.
A Visited Network may create an Operator-NAS-Identifier via many A Visited Network may create an Operator-NAS-Identifier via many
methods. The value SHOULD be cryptographically strong, and SHOULD be methods. The value SHOULD be cryptographically strong, and SHOULD be
verifiable by the Visited Network, without requiring it to track verifiable by the Visited Network, without requiring it to track in a
every individual value of Operator-NAS-identifier in a database. database every individual value of Operator-NAS-identifier which was
issued.
Exactly how this requirement is implemented is outside of the scope Exactly how this requirement is implemented is outside of the scope
of this document. of this document.
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 proxies, both CoA proxies and
RADIUS proxies. For the purpose of this section, we assume that each RADIUS proxies. For the purpose of this section, we assume that each
RADIUS proxy shares a common administration with a corresponding CoA RADIUS proxy shares a common administration with a corresponding CoA
proxy, and that the two systems can communicate electronically. proxy, and that the two systems can communicate electronically.
There is no requirement that these systems are co-located. There is no requirement that these systems are 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
which 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 verify that a Disconnect-Request or forwarding" (RPF) check to verify that a Disconnect-Request or
CoA-Request originates from an authorized Dynamic Authorization CoA-Request originates from an 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 Disconnect- "reverse path forwarding" (RPF) check to verify that a Disconnect-
Request or CoA-Request originates from an authorized Dynamic Request or CoA-Request originates from an authorized Dynamic
Authorization Client. Without this check, a proxy may forward forged Authorization Client. Without this check, a proxy may forward forged
packets, and thus contribute to the forgery problem instead of packets, and thus contribute to the forgery problem instead of
preventing it. preventing it.
Proxies which 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
CoA-NAK or Disconnect-NAK packet, which contains an Error-Cause CoA-NAK or Disconnect-NAK packet, that contains an Error-Cause
attribute having value 503 ("Session Context Not Found"). attribute having value 503 ("Session Context Not Found").
We recognize that because a RADIUS proxy will see Access-Request and We recognize that because a RADIUS proxy will see Access-Request and
Accounting-Request packets, it will have sufficient information to Accounting-Request packets, 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 Access-
skipping to change at page 13, line 31 skipping to change at page 13, line 40
These requirements are too stringent for a CoA proxy. Instead, we These requirements are too stringent for a CoA proxy. Instead, we
say that for a CoA proxy, all attributes MUST NOT be treated as say that for a CoA proxy, all attributes MUST NOT be treated as
mandatory. Proxies SHOULD perform proxying based on Operator-Name, mandatory. Proxies SHOULD perform proxying based on Operator-Name,
though other schemes are possible, but are not discussed here. though other schemes are possible, but are not discussed here.
Proxies SHOULD forward all packets as-is, with minimal changes. Only Proxies SHOULD forward all packets as-is, with minimal changes. Only
the final CoA server (i.e NAS) can make a decision on which the final CoA server (i.e NAS) can make a decision on which
attributes are mandatory and which are not. attributes are mandatory and which are not.
Where Operator-Realm and Operator-NAS-Identifier is received by a Where Operator-Realm and Operator-NAS-Identifier is 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 which forward any requirement applies to all proxies, including ones that forward any
or all of Access-Request, Accounting-Request, CoA-Request, and 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 Network MUST be removed by the
corresponding CoA proxy from packets which travel the reverse path. corresponding CoA proxy from packets that travel the reverse path.
That is, any attribute editing which is done on the "forward" path That is, any attribute editing 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 which 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 attributes sent by the NAS to it's local RADIUS
server, or contain attributes which are sent by the Home Server in server, or contain attributes that are sent by the Home Server in
order to perform a change of authorization. order to perform a change of authorization.
We note that the above requirement applies not only to Operator-Name We note that the above requirement applies not only to Operator-Name
and Operator-NAS-Identifier, but also to any future attributes which and Operator-NAS-Identifier, but also to any future attributes that
are added by a RADIUS proxy. are added by a RADIUS proxy.
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 attempting authentication In this scenario, we follow a roaming user attempting authentication
in a Visited Network. The login attempt is done via a NAS in the in 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 Network. That NAS will send an Access-Request packet to the
visited RADIUS server. The visited RADIUS server will see that the visited RADIUS server. The visited RADIUS server will see that the
user is roaming, and xwill add an Operator-Name attribute, with value 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 "1" followed by it's own realm name. e.g. "1example.com". The
visited RADIUS server MAY also add an Operator-NAS-Identifier. visited RADIUS server MAY also add an Operator-NAS-Identifier.
The visited RADIUS server will then proxy the authentication request The visited RADIUS server will then proxy the authentication request
to an upstream server. That server may be the Home Server, or it may to an upstream server. That server may be the Home Server, or it may
be a proxy. In the case of a proxy, the proxy will forward the be a proxy. In the case of a proxy, the proxy will forward the
packet, until the packet reaches the Home Server. packet, until the packet reaches the Home Server.
The Home Server will record both Operator-Name and Operator-NAS- The Home Server will record the Operator-Name and Operator-NAS-
Identfier along with other information about the users session. Identifier along with other information about the users session, if
those attributes are present in a packet.
5.2. CoA Proxing 5.2. CoA Proxying
When the Home Server determines that a user should be disconnecte, it When the Home Server determines that a user should be disconnected,
looks up the Operator-Name and Operator-NAS-Identifer, along with it looks up the Operator-Name and Operator-NAS-Identifer, along with
other user session identifiers as described in [RFC5176]. The Home other user session identifiers as described in [RFC5176]. The Home
Server then looks up the realm from the Operator-Name attribute in Server then looks up the realm from the Operator-Name attribute in
the logical AAA routing table, in order to find the CoA server for the logical AAA routing table, in order to find the "next hop" CoA
that realm (which may be a proxy). The Disconnect-Request is then server for that realm (that may be a proxy). The Disconnect-Request
sent to that CoA server. 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 similar lookup as done by the Home Server. The packet is then
proxied repeatedly until it reaches the Visited Network. 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 recieve 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 (if available) attribute 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 Opertor-NAS-Identifier attribute, the Visited Network may
use other means to locate the NAS, such as consulting a local 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-Identifer attributes are then
removed fromt he packet, and it is then sent to the CoA server. removed from the packet, and it is then sent to 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 return 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 [RFC6929] Section This specification incorporates by reference the [RFC6929] Section
skipping to change at page 15, line 47 skipping to change at page 16, line 5
8.1. Normative References 8.1. Normative References
[RFC2119] [RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March, 1997. Levels", RFC 2119, March, 1997.
[RFC2865] [RFC2865]
Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC5176]
Chiba, M. et al, "Dynamic Authorization Extensions to Remote
Authentication Dial In User Service (RADIUS)", RFC 5176, January
2008.
[RFC5580] [RFC5580]
Tschofenig H., Ed. "Carrying Location Objects in RADIUS and Tschofenig H., Ed. "Carrying Location Objects in RADIUS and
Diameter", RFC 5580, August 2009. Diameter", RFC 5580, August 2009.
[RFC6929] [RFC6929]
DeKok A. and Lior, A., "Remote Authentication Dial-In User Service DeKok A. and Lior, A., "Remote Authentication Dial-In User Service
(RADIUS) Protocol Extensions", RFC 6929, April 2013. (RADIUS) Protocol Extensions", RFC 6929, April 2013.
[RFC7542] [RFC7542]
DeKok A., "The Network Access Identifier", RFC 7542, May 2015. DeKok A., "The Network Access Identifier", RFC 7542, May 2015.
[RFC8044] [RFC8044]
DeKok A., "Data Types in the Remote Authentication Dial-In User DeKok A., "Data Types in the Remote Authentication Dial-In User
Service Protocol (RADIUS)", RFC 8044, January 2017. Service Protocol (RADIUS)", RFC 8044, January 2017.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key
Words", RFC 8174, May 2017.
8.2. Informative References 8.2. Informative References
[RFC2866] [RFC2866]
Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC5176]
Chiba, M. et al, "Dynamic Authorization Extensions to Remote
Authentication Dial In User Service (RADIUS)", RFC 5176, January
2008.
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. 43 change blocks. 
81 lines changed or deleted 99 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/