draft-ietf-radext-coa-proxy-05.txt   draft-ietf-radext-coa-proxy-06.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 Category: Standards Track
<draft-ietf-radext-coa-proxy-05.txt> <draft-ietf-radext-coa-proxy-06.txt>
30 July 2018 15 August 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-05.txt draft-ietf-radext-coa-proxy-06.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. That document suggests that proxying these
proxying these messages is possible, but gives no guidance as to how messages is possible, but gives no guidance as to how it is done.
that is done. This specification corrects that omission for This specification corrects that omission for scenarios where
scenarios where networks use Realm-based proxying as defined in networks use Realm-based proxying as defined in RFC 7542.
[RFC7542].
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 44 skipping to change at page 1, line 43
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 January 30, 2019. This Internet-Draft will expire on February 15, 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 12 skipping to change at page 3, line 12
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction ............................................. 4 1. Introduction ............................................. 4
1.1. Terminology ......................................... 4 1.1. Terminology ......................................... 4
1.2. Requirements Language ............................... 5 1.2. Requirements Language ............................... 5
2. Problem Statement ........................................ 6 2. Problem Statement ........................................ 6
2.1. Typical RADIUS Proxying ............................. 6 2.1. Typical RADIUS Proxying ............................. 6
2.2. CoA Processing ...................................... 6 2.2. CoA Processing ...................................... 7
2.3. Failure of CoA Proxying ............................. 7 2.3. Failure of CoA Proxying ............................. 7
3. How to Perform CoA Proxying .............................. 7 3. How to Perform CoA Proxying .............................. 8
3.1. Changes to Access-Request and Accounting-Request pack 8 3.1. Changes to Access-Request and Accounting-Request pack 8
3.2. Proxying of CoA-Request and Disconnect-Request packet 8 3.2. Proxying of CoA-Request and Disconnect-Request packet 9
3.3. Operator-NAS-Identifier ............................. 9 3.3. Reception of CoA-Request and Disconnect-Request packe 10
4. Requirements ............................................. 11 3.4. Operator-NAS-Identifier ............................. 11
4.1. Requirements on Home Servers ........................ 11 4. Requirements ............................................. 13
4.2. Requirements on Visited Networks .................... 11 4.1. Requirements on Home Servers ........................ 13
4.3. Requirements on Proxies ............................. 12 4.2. Requirements on Visited Networks .................... 14
4.3.1. Security Requirements on Proxies ............... 12 4.3. Requirements on Proxies ............................. 14
4.3.2. Filtering Requirements on Proxies .............. 13 4.3.1. Security Requirements on Proxies ............... 14
5. Functionality ............................................ 14 4.3.2. Filtering Requirements on Proxies .............. 16
5.1. User Login .......................................... 14 5. Functionality ............................................ 17
5.2. CoA Proxying ........................................ 14 5.1. User Login .......................................... 17
6. Security Considerations .................................. 15 5.2. CoA Proxying ........................................ 17
7. IANA Considerations ...................................... 15 6. Security Considerations .................................. 18
8. References ............................................... 15 6.1. RADIUS Security and Proxies ......................... 18
8.1. Normative References ................................ 15 6.2. Security of the Operator-NAS-Identifier Attribute ... 19
8.2. Informative References .............................. 16 7. IANA Considerations ...................................... 20
8. References ............................................... 20
8.1. Normative References ................................ 20
8.2. Informative References .............................. 21
1. Introduction 1. Introduction
RFC 5176 [RFC5176] defines Change of Authorization (CoA) and RFC 5176 [RFC5176] defines Change of Authorization (CoA) and
Disconnect Message (DM) behavior for RADIUS. Section 3.1 of that Disconnect Message (DM) behavior for RADIUS. Section 3.1 of
document suggests that proxying these messages is possible, but gives [RFC5176] suggests that proxying these messages is possible, but
no guidance as to how that is done. This omission means that in gives no guidance as to how that is done. This omission means that
practice, proxying of CoA packets is impossible. in practice, proxying of CoA packets is impossible.
We partially correct that ommission here by explaining how proxying We partially correct that ommission here by explaining how proxying
of these packets can be done by leveraging an existing RADIUS of these packets can be done by leveraging an existing RADIUS
attribute, Operator-Name (Section 4.1 of [RFC5580]). We then explain attribute, Operator-Name (Section 4.1 of [RFC5580]). We then explain
how this attribute can be used by CoA proxies to route packets how this attribute can be used by proxies to route packets
"backwards" through a RADIUS proxy chain to the Visited Network. We "backwards" through a RADIUS proxy chain from a Home Netowrk to a
introduce a new attribute; Operator-NAS-Identifier, which permits Visited Network. We then introduce a new attribute; Operator-NAS-
packets to be routed from the RADIUS server at the Visited Network to Identifier. This attribute permits packets to be routed from the
the NAS. We then explain how use of this attribute can increase RADIUS server at the Visited Network to the NAS.
privacy of the internal implementation of the visited network.
This correction is limited to the use-case of CoA proxying to Realm- This correction is limited to the use-case of Realm-based proxying as
based proxying as defined in [RFC7542]. Other forms of CoA proxying defined in [RFC7542]. Other forms of proxying are possible, but are
are possible, but are not specified here. not discussed 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 that they do not decrease the security of the
network.
1.1. Terminology 1.1. Terminology
This document frequently uses the following terms: This document frequently uses the following terms:
CoA CoA
Change of Authorization, e.g. CoA-Request, or CoA-ACK, or CoA-NAK, Change of Authorization, e.g. CoA-Request, or CoA-ACK, or CoA-NAK,
as defined in [RFC5176]. That specification also defines as defined in [RFC5176]. That specification also defines
Disconnect-Request, Disconnect-ACK, and Disconnect-NAK. For Disconnect-Request, Disconnect-ACK, and Disconnect-NAK. For
skipping to change at page 6, line 8 skipping to change at page 6, line 8
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Problem Statement 2. Problem Statement
This section describes how RADIUS proxying works, how CoA packets This section describes how RADIUS proxying works, how CoA packets
work, and why CoA proxying as discussed in RFC 5176 is insufficient work, and why CoA proxying as discussed in [RFC5176] is insufficient
in practice. to create a working system.
2.1. Typical RADIUS Proxying 2.1. Typical RADIUS Proxying
When a RADIUS server proxies an Access-Request packet, it typically When a RADIUS server proxies an Access-Request packet, it typically
does so based on the contents of the User-Name attribute, which does so based on the contents of the User-Name attribute, which
contains a Network Access Identifier [RFC7542]. Other methods are contains a Network Access Identifier (NAI) [RFC7542]. This
possible, but we restrict ourselves to this usage, as it is the most specification describes how to use the NAI in order to proxy CoA
common one. packets across multiple hops. Other methods of proxying CoA packets
are possible, but are not discussed here.
The proxy server looks up the "Realm" portion of the NAI in a logical In order to determing the "next hop" for a packet, the proxying
AAA routing table, as described in Section 3 of [RFC7542]. The entry server looks up the "Realm" portion of the NAI in a logical AAA
in that table is the "next hop" to which the packet is sent. This routing table, as described in Section 3 of [RFC7542]. The entry in
"next hop" may be another proxy, or it may be the home server for that table contains information about the "next hop" to which the
that realm. packet is sent. This information can be IP address, shared secret,
certificate, etc. The "next hop" may also be another proxy, or it
may be the Home Server for that realm.
If the "next hop" is a proxy, it will perform the same Realm lookup, If the "next hop" is a proxy, that proxy will perform the same Realm
and then proxy the packet. Alternatively, if the "next hop" is the lookup, and then proxy the packet as above. At some point, the "next
Home Server for that realm, it will try to authenticate the user, and hop" will be the Home Server for that realm.
respond with an Access-Accept, Access-Reject, or Access-Challenge.
The RADIUS client will match the response packet to an outstanding The Home Server validates the NAI in the User-Name attribute against
request. If the client is part of a proxy, it will then proxy that the list of Realms hosted by the Home Network. If there is no match,
response packet in turn to the system that originated the Access- then an Access-Reject is returned. All other packets are processed
Request. This process occurs until the response packet arrives at through local site rules, which result in an appropriate response
the NAS. packet being sent. This response packet can be Access-Accept,
Access-Challenge, or Access-Reject.
The RADIUS client receiving that response packet will match it to an
outstanding request. If the client is part of a proxy, the proxy
will then send that response packet in turn to the system that
originated the Access-Request. This process occurs until the
response packet arrives at the NAS.
The proxies are typically stateful with respect to ongoing request / 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. That
a response has been received by the proxy, it can discard all is, once a response has been sent by the proxy, it can discard all
information about the request packet. information about the request packet, other than what is needed for
detecting retransmissions as per Section 2.2.2 of [RFC5080].
The same proxy method is used for Accounting-Request packets. The The same method is used to proxy Accounting-Request packets. The
combination of the two methods allows proxies to connect Visited combination of the two methods allows proxies to connect Visited
Networks to Home Networks for all AAA purposes. Networks to Home Networks for all AAA purposes.
2.2. CoA Processing 2.2. CoA Processing
[RFC5176] describes how CoA clients send packets to CoA servers. We [RFC5176] describes how CoA clients send packets to CoA servers. We
note that system comprising the CoA client is typically co-located note that system comprising the CoA client is typically co-located
with, or is the same as, the RADIUS server. Similarly, the CoA with, or is the same as, the RADIUS server. Similarly, the CoA
server is a system that is either co-located with, or is the same as, server is a system that is either co-located with, or is the same as,
the RADIUS client. the RADIUS client.
In the case of packets sent inside of one network, the source and In the case of packets sent inside of one network, the source and
destination of CoA packets is locally determined. There is thus no destination of CoA packets are locally determined. There is thus no
need for standardization of that process, as networks are free to need for standardization of that process, as networks are free to
send CoA packets whenever they want, for whatever reason they want. send CoA packets whenever they want, for whatever reason they want.
2.3. Failure of CoA Proxying 2.3. Failure of CoA Proxying
The situation is more complicated when multiple networks are The situation is more complicated when proxies are involved.
involved. [RFC5176] suggests that CoA proxying is permitted, but [RFC5176] suggests that CoA proxying is permitted, but that
makes no suggestions for how it should be done. specification makes no suggestions for how that proxying should be
done.
If proxies tracked user sessions, it might be possible for a proxy to If proxies were to track user sessions, it would be possible for a
match an incoming CoA-Request to a user session, and then to proxy proxy to match an incoming CoA packet to a user session, and then to
that packet to the RADIUS client that originated the Access-Request proxy the CoA packet to the RADIUS client that originated the Access-
for that sessions. Request for that session. There are many problems with such a
scenario.
There are many problems with such a scenario. The CoA server may, in The CoA server may, in fact, not be co-located with the RADIUS
fact, not be co-located with the RADIUS client. The RADIUS client client. In which case it may not have access to user session
may be down, but there may be a different CoA server which could information for performing the reverse path forwarding.
successfully process the packet. User session tracking can be
expensive and complicated for a proxy, and many proxies do not record
user sessions. Finally, [RFC5176] is silent on the topic of what
attributes constitute "session identification attributes", which
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 CoA server may be down, but there may be a different CoA server
performed when using the behavior defined in [RFC5176]. which could successfully process the packet. The CoA client should
then fail over to a different CoA server. If the reverse path is
restricted to be the same as the forward path, then such fail-over is
not possible.
In a roaming consortium, the proxies may forward traffic for tens of
millions of users. Tracking each user session can be expensive and
complicated, and doing so does not scale well. For that reason, most
proxies do not record user sessions.
Even if the proxy recorded user sessions, [RFC5176] is silent on the
topic of what attributes constitute "session identification
attributes". That silence means it is impossible for a proxy to
determine if a CoA packet matches a particular user session.
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 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 Realm-based proxying on
the reverse path, just as with the forward path. In order for the
reverse path proxying to work, the proxy decision must be based on an
attribute other than User-Name.
The reverse path proxying can be done by using the Operator-Name
attribute defined in [RFC5580], Section 4.1. We repeat a portion of attribute defined in [RFC5580], Section 4.1. We repeat a portion of
that definition here for clarity: that definition here for clarity:
This attribute carries the operator namespace identifier and the This attribute carries the operator namespace identifier and the
operator name. The operator name is combined with the namespace operator name. The operator name is combined with the namespace
identifier to uniquely identify the owner of an access network. identifier to uniquely identify the owner of an access network.
Followed by a description of the REALM namespace: Followed by a description of the REALM namespace:
REALM ('1' (0x31)): REALM ('1' (0x31)):
skipping to change at page 8, line 9 skipping to change at page 8, line 37
The REALM operator namespace can be used to indicate operator The REALM operator namespace can be used to indicate operator
names based on any registered domain name. Such names are names based on any registered domain name. Such names are
required to be unique, and the rights to use a given realm name required to be unique, and the rights to use a given realm name
are obtained coincident with acquiring the rights to use a are obtained coincident with acquiring the rights to use a
particular Fully Qualified Domain Name (FQDN). ... particular Fully Qualified Domain Name (FQDN). ...
In short, the Operator-Name attribute contains the an ASCII "1", In short, the Operator-Name attribute contains the an ASCII "1",
followed by the Realm of the Visited Network. e.g. for the followed by the Realm of the Visited Network. e.g. for the
"example.com" realm, the Operator-Name attribute contains the text "example.com" realm, the Operator-Name attribute contains the text
"1example.com". This information is precisely what is needed by "1example.com". This information is precisely what is needed by
intermediate nodes, in order to perform CoA proxying. intermediate nodes in order to perform CoA proxying.
The remainder of this document describes how CoA proxying can be
performed by using the Operator-Name attribute. We describe how the
forward path has to change in order to allow reverse path proxying.
We then describe how reverse path proxying works. And we describe
how Visited Networks and Home Networks have to behave in order for
CoA proxying to work.
3.1. Changes to Access-Request and Accounting-Request packets 3.1. Changes to Access-Request and Accounting-Request packets
When a Visited Network proxies an Access-Request or Accounting- When a Visited Network proxies an Access-Request or Accounting-
Request packet outside of its network, it SHOULD include an Operator- Request packet outside of its network, the Visited Network SHOULD
Name attribute in the packet, as discussed in Section 4.1 of include an Operator-Name attribute in the packet, as discussed in
[RFC5580]. The contents of the Operator-Name should be "1", followed Section 4.1 of [RFC5580]. The contents of the Operator-Name should
by the realm name of the Visited Network. Where the Visited Network be "1", followed by the realm name of the Visited Network. Where the
has more than one realm name, a "canonical" one should be chosen, and Visited Network has more than one realm name, a "canonical" one
used for all packets. should be chosen, and 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- any 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 a single user session was activee simultaneously in two like a single user session was active simultaneously in two different
different Visited Networks, which is impossible. Visited Networks, which is impossible.
Proxies that record user session information SHOULD also record Proxies that record user session information SHOULD also record
Operator-Name. Proxies that do not record user session information Operator-Name. Proxies that do not record user session information
do not need to record Operator-Name. do not need to record Operator-Name.
Home Networks SHOULD record Operator-Name along with any other Home Networks SHOULD record Operator-Name along with any other
information that they record about user sessions. Home Networks that information that they record about user sessions. Home Networks that
expect to send CoA packets to Visited Networks MUST record Operator- expect to send CoA packets to Visited Networks MUST record Operator-
Name for each user session that originates from a Visited Network. Name for each user session that originates from a Visited Network.
Failure to record the Operator-Name would mean that the Home Network Failure to record the Operator-Name would mean that the Home Network
would not know where to send any CoA packet. would not know where to send any CoA packet.
Networks that contain both the RADIUS client and RADIUS server do not Networks that host both the RADIUS client and RADIUS server do not
need to create, record or track Operator-Name. That is, if the need to create, record or track Operator-Name. That is, if the
Visited Network and Home Network are the same, there is no need to Visited Network and Home Network are the same, there is no need to
use the Operator-Name attribute. use the Operator-Name attribute.
3.2. Proxying of CoA-Request and Disconnect-Request packets 3.2. Proxying of CoA-Request and Disconnect-Request packets
When a Home Network wishes to send a CoA-Request or Disconnect- When a Home Network wishes to send a CoA-Request or Disconnect-
Request packet to a Visited Network, it MUST include an Operator-Name Request packet to a Visited Network, it MUST include an Operator-Name
attribute in the packet. The value of the Operator-Name MUST be the attribute in the CoA packet. The value of the Operator-Name MUST be
value which was recorded earlier for that user session. the 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 or more "next hop" to include a mapping between "utf8-realm" and one or more "next hop"
CoA servers. CoA servers.
skipping to change at page 9, line 24 skipping to change at page 10, line 10
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 that receive the CoA packet MUST look up the realm from the Proxies that receive the CoA packet will look up the realm from the
Operator-Name in a logical "realm routing table", as with Home Operator-Name 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 proxy for the realm
in that table. This process continues with any subsequent proxies which was found in that table. This process continues with any
until the packet reaches the Visited Network. subsequent proxies until the packet reaches a public CoA server at
the Visited Network.
The Visited Network can then send the CoA packet to the NAS, and Where the realm is unknown, the proxy MUST return a NAK packet that
return any response packet back up the proxy chain to the Home contains an Error-Cause attribute having value 502 ("Request Not
Server. Routable").
The only missing piece here is how the Visited Network gets the Proxies which receive a CoA packet MUST NOT use the NAI from the
packet from its CoA server to the NAS. The Visited Network could use User-Name in order to make proxying decisions. Doing so would result
NAS-Identifier, NAS-IP-Address, or NAS-IPv6-Address, but these in the CoA packet being forwarded to the Home Network, while the
attributes may be incorrect, or may be missing entirely. user's session is in the Visited Network.
These attributes may be incorrect because proxies that forward We also update Section 5 of [RFC5580] to permit CoA-Request and
Access-Request packets often re-write them for internal policy Disconnect-Request packets to contain zero or one instances of the
reasons. These attributes may be missing, because the Visited Operator-Name attribute.
Network may not want all upstream proxies and Home Servers to have
detailed information about the internals of its private network.
We therefore need a way to identifier a NAS in the Visited Network, 3.3. Reception of CoA-Request and Disconnect-Request packets
in a way which is both private, and which does not use any existing
attribute.
3.3. Operator-NAS-Identifier After some proxying, the CoA packet will be recieved by the CoA
server in the Visited Network. That CoA server MUST validate the NAI
in the Operator-Name attribute against the list of realms hosted by
the Visited Network. If the realm is not found, then the CoA server
MUST return a NAK packet that contains an Error-Cause attribute
having value 502 ("Request Not Routable").
The Operator-NAS-Identifier attribute contains opaque information Some Home Networks will not have permission to send CoA packets to
that identifies a NAS in a Visited Network. It MAY appear in the the Visited Network. The CoA server SHOULD therefore also validate
following packets: Access-Request, Accounting-Request, CoA-Request, the NAI contained in the User-Name attribute. If the Home Network is
or Disconnect-Request. Operator-NAS-Identifier MUST NOT appear in not permitted to send CoA packets to this Visited Network, then the
any other packet. CoA server MUST return a NAK packet that contains an Error-Cause
attribute having value 502 ("Request Not Routable").
These checks make it more difficult for a malicious Home Network to
scan roaming network in order to determine which Visited Network
hosts which Realm. That information should be known to all parties
in advance, and exchanged via methods outside of this specification.
Those methods will typically be in the form of contractual
relationships between parties, or as membership in a roaming
consortium.
The CoA server in the Visited Network will also ensure that the
Operator-NAS-Identifier attribute is known, as described below. If
the attribute matches a known NAS, then the packet will be sent to
that NAS. Otherwise, the CoA server MUST return a NAK packet that
contains an Error-Cause attribute having value 403 ("NAS
Identification Mismatch").
All other received packets are processed as per local site rules, and
will result in an appropriate response packet being sent. This
process mirrors the method used to process Access-Request and
Accounting-Request packets described above.
The processing by Visited Network will normally include sending the
CoA packet to the NAS; having the NAS process it; and then returning
any response packet back up the proxy chain to the Home Server.
The only missing piece here is the procedure by which the Visited
Network gets the packet from its public CoA server to the NAS. The
Visited Network could use NAS-Identifier, NAS-IP-Address, or NAS-
IPv6-Address, but these attributes may have been edited by an
intermediate proxy, or the attributes may be missing entirely.
These attributes may be incorrect because proxies forwarding Access-
Request packets often re-write them for internal policy reasons.
These attributes may be missing, because the Visited Network may not
want all upstream proxies and Home Servers to have detailed
information about the internals of its private network, and may
remove them itself.
We therefore need a way to identify a NAS in the Visited Network, in
a way which is both private, and which does not use any existing
attribute. Our solution is to define an Operator-NAS-Identifier
attribute, which identifies an individual NAS in the Visited Network.
3.4. Operator-NAS-Identifier
The Operator-NAS-Identifier attribute is an opaque token that
identifies an individual NAS in a Visited Network. It MAY appear in
the following packets: Access-Request, Accounting-Request, CoA-
Request, or Disconnect-Request. Operator-NAS-Identifier MUST NOT
appear in any other packet.
Operator-NAS-Identifier MAY occur in a packet if the packet also 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.
If a packet contains more than one Operator-NAS-Identifier,
implementations MUST ignore the second and subsequent attributes, and
treat them as "invalid attributes", as discussed in Section 2.8 of
[RFC6929].
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, 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 order satisfy the requirements of Section 4.1 of [RFC2865], and
Section 4.1 of [RFC2866]. When a server receives a packet that Section 4.1 of [RFC2866]. The contents of the NAS-Identifier SHOULD
already contains an Operator-NAS-Identifer attribute, no such editing be the Realm name of the visited network.
is performed.
The Operator-NAS-Identifier attribute parallels the Operator-Name When a server receives a packet that already contains an Operator-
attribute that was defined in Section 4.1 of [RFC5580]. NAS-Identifer attribute, no such editing is performed.
We suggest that the contents of the NAS-Identifier be the Realm name The Operator-NAS-Attribute MUST NOT be added to any packet by any
of the Visited Network. That is, for everyone outside of the Visited other proxy or server in the network. Only the Visited Network (i.e.
Network, there is only one NAS: the Visited Network itself. For the the operator) can name a NAS which is inside of the Visited Network.
Visited Network, the identity of the NAS is private information,
which is opaque to everyone else.
The new Operator-NAS-Identifier attribute is defined as follows. The result of these requirements is that for everyone outside of the
Visited Network, there is only one NAS: the Visited Network itself.
And, the Visited Network is able to identify its own NASes to its own
satisfaction.
This usage of the Operator-NAS-Identifier attribute parallels the
Operator-Name attribute which was defined in Section 4.1 of
[RFC5580].
The Operator-NAS-Identifier attribute is defined as follows.
Description 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
4 to 23. 4 to 23.
Implementations supporting this attribute MUST be able to handle Implementations supporting this attribute MUST be able to handle
between one (1) and twenty (20) octets of data. Implementations between one (1) and thirty-two (32) octets of data.
creating an Operator-NAS-Identifier MUST NOT create attributes Implementations creating an Operator-NAS-Identifier MUST NOT
with more than twenty octets of data. A twenty octet string is create attributes with more than sixty-four octets of data. A
more than sufficient to individually address all of the NASes on thirty-two octet string should be more than sufficient for future
the planet. uses.
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 user's session. In practice, this requirement
means that for non-trivial use-cases, the Visited Network will means that the Visited Network has two practical methods to create
either track these tokens in a database, or it will create tokens the value.
that can be decoded in order to reveal the identity of the NAS.
The first method is to create an opaque token per NAS, and then to
store that information in a database. The database can be
configured to allow querying by NAS IP address in order to find
the correct Operator-NAS-Identifier. The database can also be
configured to allow querying by Operator-NAS-Identifier in order
to find the correct NAS IP address.
The second method is to encrypt the NAS IP address with some local
encryption key. The output of that encryption is data which can
be used as the value of Operator-NAS-Identifier. On reception of
a CoA packet, the local encryption key can be used to decrypt the
value of Operator-NAS-Identifier, in order to determine the actual
NAS IP address.
Note that there is no requirement that the value of Operator-NAS-
Identifier be checked for integrity. Modification of the value
can only result in the erroneous transaction being rejected.
We note that the Access-Request and Accounting-Request packets
often contain the MAC address of the NAS. There is therefore no
requirement that Operator-NAS-Identifier obsfuscate or hide in any
way the total number of NASes in a Visited Network. That
information is already public knowledge.
4. Requirements 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
Operator-NAS-Identifier it has recorded for that session. verbatim any 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 next few sections describe how other participants in the RADIUS
participants in the RADIUS ecosystem can enforce this requirement. ecosystem can help to enforce this requirement.
4.2. Requirements on Visited Networks 4.2. Requirements on Visited Networks
A Visited Network which receives a CoA packet that will be proxied A Visited Network which receives a CoA packet that will be proxied to
MUST perform all of the operations required for proxies by Section a NAS MUST perform all of the operations required for proxies by
4.3.2. This requirement is because we assume that the Visited Section 4.3.2. This requirement is because we assume that the
Network has a proxy in between the NAS and any external (i.e. third- Visited Network has a proxy in between the NAS and any external (i.e.
party) proxy. Situations where a NAS sends packets directly to a third-party) proxy. Situations where a NAS sends packets directly to
third-party RADIUS server are outside of the scope of this a third-party RADIUS server are outside of the scope of this
specification. specification.
Due to the limited number of attributes allowed in CoA packets by The Visited Network uses the content of the Operator-NAS-Identifier
[RFC5176] Section 2.3, a Visited Network MUST remove the Operator- attribute to determine which NAS will receive the packet.
Name and Operator-NAS-Identifier attributes from any CoA-Request or
Disconnect-Request packet prior to proxying that packet to the final
CoA server (i.e. NAS). This requirement is phrase more generically
below, in Section 4.3.2.
A Visited Network may create an Operator-NAS-Identifier via many The Visited Network MUST remove the Operator-Name and Operator-NAS-
methods. The value SHOULD be cryptographically strong, and SHOULD be Identifier attributes from any CoA packet packet prior to sending
verifiable by the Visited Network, without requiring it to track in a that packet to the final CoA server (i.e. NAS). This step is
database every individual value of Operator-NAS-identifier which was necessary due to the the limits of Section 2.3 of [RFC5176].
issued.
Exactly how this requirement is implemented is outside of the scope The Visited Network MUST also ensure that the CoA packet sent to the
of this document. NAS contains one of the following attributes: NAS-IP-Address, NAS-
IPv6-Address, or NAS-Identifier. This step is the inverse of the
removal required above in Section 3.4.
In general, the NAS should only receive attributes which identify or
modify a user's session. It is not appropriate to send a NAS
attributes which are used only for inter-proxy signaling.
4.3. Requirements on Proxies 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 for these systems to be co-located.
4.3.1. Security Requirements on Proxies 4.3.1. Security Requirements on Proxies
Section 6.1 of [RFC5176] has some security requirements on proxies Section 6.1 of [RFC5176] has some security requirements on proxies
that handle CoA-Request and Disconnect-Request packets: that handle CoA-Request and Disconnect-Request packets:
... a proxy MAY perform a "reverse path ... a proxy MAY perform a "reverse path
forwarding" (RPF) check to 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 CoA packet
Request or CoA-Request originates from an authorized Dynamic originates from an authorized Dynamic Authorization Client. Without
Authorization Client. Without this check, a proxy may forward forged this check, a proxy may forward packets from misconfigured or
packets, and thus contribute to the forgery problem instead of malicious parties, and thus contribute to the problem instead of
preventing it. preventing it. Where the check fails, the proxy MUST return a NAK
packet that contains an Error-Cause attribute having value 502
("Request Not Routable").
Proxies that record user session information SHOULD verify the 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, that contains an Error-Cause NAK packet that contains an Error-Cause attribute having value 503
attribute having value 503 ("Session Context Not Found"). ("Session Context Not Found"). These checks cannot be mandated due
to the fact that [RFC5176] offers no advice on which attributes are
used to to identify a user's session.
We recognize that because a RADIUS proxy will see Access-Request and 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-
Reject for Access-Request packets, and can change authorization Reject for Access-Request packets, and can change authorization
skipping to change at page 13, line 20 skipping to change at page 15, line 51
The largest problem is that there are no provisions in RADIUS for The largest problem is that there are no provisions in RADIUS for
"end to end" security. That is, the Visited Network and Home Network "end to end" security. That is, the Visited Network and Home Network
cannot communicate privately in the presence of proxies. This cannot communicate privately in the presence of proxies. This
limitation originates from the design of RADIUS for Access-Request limitation originates from the design of RADIUS for Access-Request
and Accounting-Request packets. That limitation is then carried over and Accounting-Request packets. That limitation is then carried over
to CoA-Request and Disconnect-Request packets. to CoA-Request and Disconnect-Request packets.
We cannot therefore prevent proxies or Home Servers from forging CoA We cannot therefore prevent proxies or Home Servers from forging CoA
packets. We can only create scenarios where that forgery is hard to packets. We can only create scenarios where that forgery is hard to
perform, and/or is likely to be detected. perform, and/or is likely to be detected, and/or has no effect.
4.3.2. Filtering Requirements on Proxies 4.3.2. Filtering Requirements on Proxies
Section 2.3 of [RFC5176] makes the following requirement for CoA Section 2.3 of [RFC5176] makes the following requirement for CoA
servers: servers:
In CoA-Request and Disconnect-Request packets, all attributes In CoA-Request and Disconnect-Request packets, all attributes
MUST be treated as mandatory. MUST be treated as mandatory.
These requirements are too stringent for a CoA proxy. Instead, we These requirements are too stringent for a CoA proxy. Only the final
say that for a CoA proxy, all attributes MUST NOT be treated as CoA server (i.e NAS) can make a decision on which attributes are
mandatory. Proxies SHOULD perform proxying based on Operator-Name, mandatory and which are not.
though other schemes are possible, but are not discussed here.
Proxies SHOULD forward all packets as-is, with minimal changes. Only
the final CoA server (i.e NAS) can make a decision on which
attributes are mandatory and which are not.
Where Operator-Realm and Operator-NAS-Identifier is received by a Instead, we say that for a CoA proxy, all attributes MUST NOT be
treated as mandatory. Proxies implementing this specification MUST
perform proxying based on Operator-Name. Other schemes are possible,
but are not discussed here. Proxies SHOULD forward all packets as-
is, with minimal changes.
We note that some NAS implementations currently treat signaling
attributes as mandatory. For example, some NAS implementations will
NAK any CoA packet that contains a Proxy-State attribute. While this
behavior is based on a straightforward reading of the above text, it
causes problems in practice.
We update Section 2.3 of [RFC5176] to say that in CoA-Request and
Disconnect-Request packets, the NAS MUST NOT treat as mandatory any
attribute which is known to not affect the users session. For
example, the Proxy-State attribute. Proxy-State is an attribute used
for proxy-to-proxy signaling. It cannot affect the user's session,
and therefore Proxy-State (and similar attributes) MUST be ignored by
the NAS.
When Operator-Realm and/or Operator-NAS-Identifier are received by a
proxy, the proxy MUST pass those attributes through unchanged. This proxy, the proxy MUST pass those attributes through unchanged. This
requirement applies to all proxies, including ones that forward any requirement applies to all proxies, including 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 that travel the reverse path. corresponding CoA proxy from packets traversing the reverse path.
That is, any attribute editing that is done on the "forward" path That is, any 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 that The result is that a NAS will only ever receive CoA packets that
either contain attributes sent by the NAS to it's local RADIUS either contain attributes sent by the NAS to it's local RADIUS
server, or contain attributes that 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 Finally, we extend the above requirement not only to Operator-Name
and Operator-NAS-Identifier, but also to any future attributes that and Operator-NAS-Identifier, but also to any future attributes that
are added by a RADIUS proxy. are added for proxy-to-proxy signaling.
5. Functionality 5. Functionality
This section describes how the two attributes work together to permit This section describes how the two attributes work together to permit
CoA proxying. CoA proxying.
5.1. User Login 5.1. User Login
In this scenario, we follow a roaming user who is attempting to log
In this scenario, we follow a roaming user attempting authentication in to 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 will 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
NAS identification attributes are also edited, as required by Section
3.4, above.
The visited RADIUS server will then proxy the authentication request The Visited Server will then proxy the authentication request to an
to an upstream server. That server may be the Home Server, or it may upstream server. That server may be the Home Server, or it may be a
be a proxy. In the case of a proxy, the proxy will forward the proxy. In the case of a proxy, the proxy will forward the packet,
packet, until the packet reaches the Home Server. until the packet reaches the Home Server.
The Home Server will record the Operator-Name and Operator-NAS- The Home Server will record the Operator-Name and Operator-NAS-
Identifier along with other information about the users session, if Identifier along with other information about the users session, if
those attributes are present in a packet. those attributes are present in a packet.
5.2. CoA Proxying 5.2. CoA Proxying
When the Home Server determines that a user should be disconnected, At some later point in time, the Home Server determines that a user
it looks up the Operator-Name and Operator-NAS-Identifer, along with session should have its authorization changed, or be disconnected.
other user session identifiers as described in [RFC5176]. The Home The Home Server looks up the Operator-Name and Operator-NAS-
Server then looks up the realm from the Operator-Name attribute in Identifer, along with other user session identifiers as described in
the logical AAA routing table, in order to find the "next hop" CoA [RFC5176]. The Home Server then looks up the realm from the
server for that realm (that may be a proxy). The Disconnect-Request Operator-Name attribute in the logical AAA routing table, in order to
is then sent to that CoA server. find the "next hop" CoA server for that realm (that may be a proxy).
The CoA request is then sent to that CoA server.
The CoA server receives the request, and if it is a proxy, performs a 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 receive the CoA-Request packet, and will use The Visited Network will receive the CoA-Request packet, and will use
the Operator-NAS-Identifier (if available) attribute to determine the Operator-NAS-Identifier (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 that tracks user sessions. database which tracks user sessions.
The Operator-Name and Operator-NAS-Identifer attributes are then The Operator-Name and Operator-NAS-Identifer attributes are then
removed from the packet, and it is then sent to the CoA server. removed from the packet; one of NAS-IP-Address, or NAS-IPv6-Address,
or NAS-Identifier is added to the packet; and the packet is then sent
to the CoA server.
If no CoA server can be found, the Visited Network return a CoA-NAK 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 Section 11 of
11. In short, RADIUS has many known issues which are discussed in [RFC6929]. In short, RADIUS has many known issues which are
detail there, and which do not need to be repeated here. discussed in detail there, and which do not need to be repeated here.
This specification adds one new attribute, and defines new behavior This specification adds one new attribute, and defines new behavior
for RADIUS proxying. As this behavior mirrors existing RADIUS for RADIUS proxying. As this behavior mirrors existing RADIUS
proxying, we do not believe that it introduces any new security proxying, we do not believe that it introduces any new security
issues. issues. We note, however, that RADIUS proxying has a series of
inherent security issues.
The Operator-NAS-Identifier SHOULD be created by the Visited Network 6.1. RADIUS Security and Proxies
such that its contents are opaque to all other parties. This ensures
that anyone observing unencrypted RADIUS traffic gains no information The requirement that packets be signed with a shared secret means
about the internals of the Visited Network. that a CoA packet can only be received from a trusted party. Or
transitively, received from a third party via a trusted party. This
security provision of the base RADIUS protocol makes it impossible
for untrusted parties to affect the user's session.
When RADIUS proxying is performed, all packets are signed on a hop-
by-hop basis. Any intermediate proxy can therefore forge packets,
replay packets, or modify the contents of any packets entirely
without detection. As a result, the secure operation of such a
system depends largely on trust, instead of on technical means.
CoA packet proxying has all of the same issues as noted above. We
note that the proxies which see and can modify CoA packets are
generally the same proxies which can see or modify Access-Request and
Accounting-Request packets. As such, there are few additional
security implications in allowing CoA proxying.
The main security implication left is that Home Networks now have the
capability to disconnect, or change the authorization of users in a
Visited Network. As this capability is only enabled when mutual
agreement is in place, and only for those parties who can already
control the users's session, there are no new security issues with
this specification.
6.2. Security of the Operator-NAS-Identifier Attribute
Nothing in this specification depends on the security of the
Operator-NAS-Identifier attribute. The entire process would work
exactly the same if the Operator-NAS-Identifier simply contained the
NAS IP address that is hosting the user's session. The only real
downside in that situation would be that external parties would see
some additional private information about the Visited Network. They
would still, however, be unable to leverage that information to do
anything malicious.
The main reason to use an opaque token for the Operator-NAS-
Identifier is that there is no compelling reason to make the
information public. We therefore recommend that the value be simply
an opaque token. We also state that there is no requirement for
integrity protection or replay detection of this attribute. The rest
of the RADIUS protocol ensures that modification or replay of the
Operator-NAS-Identifier will either have no effect, or will have the
same effect as if the value had not been modified.
Trusted parties can modify a user's session on the NAS only when they
have sufficient information to identify that session. In practice,
this limitation means that those parties already have access to the
users's session information. Which is to say, those parties are the
proxies who are already forwarding Access-Request and Accounting-
Request packets.
Since those parties already have the ability to see and modify all of
the information about a user's session, there is no additional
security issue with allowing them to see and modify CoA packets.
In short, any security issues with the contents of Operator-NAS-
Identifier are largely limited by the security of the underlying
RADIUS protocol. This limitation means that it does not matter how
the values of Operator-NAS-Identifier are created, stored, or used.
7. IANA Considerations 7. IANA Considerations
IANA is instructed to allocate one new RADIUS attribute, as per IANA is instructed to allocate one new RADIUS attribute, as per
Section 3.3, above. Section 3.3, above. The Operator-NAS-Identifier attribute is to be
allocated from the RADIUS Attribute Types registry as follows:
Value: [ TBD-at-Registration ]
Description: Operator-NAS-Identifier
Data Type: string
Reference: [ RFC-to-be ]
8. References 8. References
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, <http://www.rfc-
editor.org/info/rfc2119>.
[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,
<http://www.rfc-editor.org/info/rfc2865>.
[RFC5080]
Nelson, D., and DeKok, A., "Common Remote Authentication Dial In
User Service (RADIUS) Implementation Issues and Suggested Fixes",
RFC 5080, December 2007, <http://www.rfc-editor.org/info/rfc5080>.
[RFC5176] [RFC5176]
Chiba, M. et al, "Dynamic Authorization Extensions to Remote Chiba, M. et al, "Dynamic Authorization Extensions to Remote
Authentication Dial In User Service (RADIUS)", RFC 5176, January Authentication Dial In User Service (RADIUS)", RFC 5176, January
2008. 2008, <http://www.rfc-editor.org/info/rfc5176>.
[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, <http://www.rfc-
editor.org/info/rfc5580>.
[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,
<http://www.rfc-editor.org/info/rfc6929>.
[RFC7542] [RFC7542]
DeKok A., "The Network Access Identifier", RFC 7542, May 2015. DeKok A., "The Network Access Identifier", RFC 7542, May 2015,
<http://www.rfc-editor.org/info/rfc7542>.
[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,
<http://www.rfc-editor.org/info/rfc8044>.
[RFC8174] [RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key
Words", RFC 8174, May 2017. Words", RFC 8174, May 2017, <http://www.rfc-
editor.org/info/rfc8174>.
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,
<http://www.rfc-editor.org/info/rfc2866>.
Authors' Addresses Authors' Addresses
Alan DeKok Alan DeKok
The FreeRADIUS Server Project The FreeRADIUS Server Project
Email: aland@freeradius.org Email: aland@freeradius.org
Jouni Korhonen Jouni Korhonen
 End of changes. 81 change blocks. 
222 lines changed or deleted 447 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/