Dynamic Authorization Proxying in Remote Authorization Dial-In User Service Protocol (RADIUS)
draft-ietf-radext-coa-proxy-09

"utf8-realm" and one or more "next hop"
   CoA servers.

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

   In practice, this process means that CoA proxying works exactly like
   "normal" RADIUS proxying, except that the proxy decision is made
   using the realm from the Operator-Name attribute, instead of using
   the realm from the User-Name attribute.

   Proxies that receive the CoA packet will look up the realm from the
   Operator-Name in a logical "realm routing table", as with Home
   Servers, above.  The packet is then sent to the proxy for the realm
   which was found in that table.  This process continues with any
   subsequent proxies until the packet reaches a public CoA server at
   the Visited Network.

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

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

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

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

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

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

DeKok, Alan                 Proposed Standard                  [Page 10]
INTERNET-DRAFT  Dynamic Authorization Proxying in RADIUS 22 January 2019

   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

DeKok, Alan                 Proposed Standard                  [Page 11]
INTERNET-DRAFT  Dynamic Authorization Proxying in RADIUS 22 January 2019

   appear in any other packet.

   Operator-NAS-Identifier MAY occur in a packet if the packet also
   contains an Operator-Name attribute.  Operator-NAS-Identifier MUST
   NOT appear in a packet if there is no Operator-Name in the packet.
   As each proxied CoA packet is sent only to one NAS, the Operator-NAS-
   Identifier attribute MUST NOT occur more than once in a packet.  If a
   packet contains more than one Operator-NAS-Identifier,
   implementations MUST treat the second and subsequent attributes as
   "invalid attributes", as discussed in Section 2.8 of [RFC6929].

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

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

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

   The result of these requirements is that for everyone outside of the
   Visited Network, there is only one NAS: the Visited Network itself.
   And, the Visited Network is able to identify its own NASes to its own
   satisfaction.

   This usage of the Operator-NAS-Identifier attribute parallels the
   Operator-Name attribute which was defined in Section 4.1 of
   [RFC5580].

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

   Description

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

   Type

      TBD.  To be assigned by IANA from the "short extended space".

DeKok, Alan                 Proposed Standard                  [Page 12]
INTERNET-DRAFT  Dynamic Authorization Proxying in RADIUS 22 January 2019

   Length

      4 to 35.

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

   Data Type

      string.  See [RFC8044] Section 3.6 for a definition.

   Value

      The contents of this attribute are an opaque token interpretable
      only by the Visited Network.

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

      The first method is to create an opaque token per NAS, and then to
      store that information in a database.  The database can be
      configured to allow querying by NAS IP address in order to find
      the correct Operator-NAS-Identifier.  The database can also be
      configured to allow querying by Operator-NAS-Identifier in order
      to find the correct NAS IP address.

      The second method is to obfuscate the NAS IP address using
      information known locally by the Visited network; for example, by
      XORing it with a locally known secret key.  The output of that
      obfuscation operation is data that can be used as the value of
      Operator-NAS-Identifier.  On reception of a CoA packet, the
      locally-known information can be used to un-obfuscate the value of
      Operator-NAS-Identifier, in order to determine the actual NAS IP
      address.

      Note that there is no requirement that the value of Operator-NAS-
      Identifier be checked for integrity.  Modification of the value
      can only result in the erroneous transaction being rejected.

      We note that the Access-Request and Accounting-Request packets
      often contain the MAC address of the NAS.  There is therefore no
      requirement that Operator-NAS-Identifier obsfuscate or hide in any

DeKok, Alan                 Proposed Standard                  [Page 13]
INTERNET-DRAFT  Dynamic Authorization Proxying in RADIUS 22 January 2019

      way the total number of NASes in a Visited Network.  That
      information is already public knowledge.

4.  Requirements

4.1.  Requirements on Home Servers

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

   A Home Server MUST NOT send CoA packets for users of other networks.
   The next few sections describe how other participants in the RADIUS
   ecosystem can help to enforce this requirement.

4.2.  Requirements on Visited Networks

   A Visited Network which receives a CoA packet that will be proxied to
   a NAS MUST perform all of the operations required for proxies by
   Section 4.3.2.  This requirement is because we assume that the
   Visited Network has a proxy in between the NAS and any external (i.e.
   third-party) proxy.  Situations where a NAS sends packets directly to
   a third-party RADIUS server are outside of the scope of this
   specification.

   The Visited Network uses the content of the Operator-NAS-Identifier
   attribute to determine which NAS will receive the packet.

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

   The Visited Network MUST also ensure that the CoA packet sent to the
   NAS contains one of the following attributes: NAS-IP-Address, NAS-
   IPv6-Address, or NAS-Identifier.  This step is the inverse of the
   removal suggested 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.

DeKok, Alan                 Proposed Standard                  [Page 14]
INTERNET-DRAFT  Dynamic Authorization Proxying in RADIUS 22 January 2019

4.3.  Requirements on Proxies

   There are a number of requirements on proxies, both CoA proxies and
   RADIUS proxies.  For the purpose of this section, we assume that each
   RADIUS proxy shares a common administration with a corresponding CoA
   proxy, and that the two systems can communicate electronically.
   There is no requirement for these systems to be co-located.

4.3.1.  Security Requirements on Proxies

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

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

   We strengthen that requirement by saying that a proxy MUST perform a
   "reverse path forwarding" (RPF) check to verify that a CoA packet
   originates from an authorized Dynamic Authorization Client.  Without
   this check, a proxy may forward packets from misconfigured or
   malicious parties, and thus contribute to the problem instead of
   preventing it.  Where the check fails, the proxy MUST return a NAK
   packet that contains an Error-Cause attribute having value 502
   ("Request Not Routable").

   Proxies that record user session information SHOULD verify the
   contents of a received CoA packet against the recorded data for that
   user session.  If the proxy determines that the information in the
   packet does not match the recorded user session, it SHOULD return a
   NAK packet that contains an Error-Cause attribute having value 503
   ("Session Context Not Found").  These checks cannot be mandated due
   to the fact that [RFC5176] offers no advice on which attributes are
   used to to identify a user's session.

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

   We suggest that the real-world effect of this security problem is
   minimal.  RADIUS proxies can already return Access-Accept or Access-
   Reject for Access-Request packets, and can change authorization
   attributes contained in an Access-Accept.  Allowing a proxy to change
   (or disconnect) a user session post-authentication is not
   substantially different from changing (or refusing to connect) a user

DeKok, Alan                 Proposed Standard                  [Page 15]
INTERNET-DRAFT  Dynamic Authorization Proxying in RADIUS 22 January 2019

   session during the initial process of authentiction.

   The largest problem is that there are no provisions in RADIUS for
   "end to end" security.  That is, the Visited Network and Home Network
   cannot communicate privately in the presence of proxies.  This
   limitation originates from the design of RADIUS for Access-Request
   and Accounting-Request packets.  That limitation is then carried over
   to CoA-Request and Disconnect-Request packets.

   We cannot therefore prevent proxies or Home Servers from forging CoA
   packets.  We can only create scenarios where that forgery is hard to
   perform, and/or is likely to be detected, and/or has no effect.

4.3.2.  Filtering Requirements on Proxies

   Section 2.3 of [RFC5176] makes the following requirement for CoA
   servers:

         In CoA-Request and Disconnect-Request packets, all attributes
         MUST be treated as mandatory.

   These requirements are too stringent for a CoA proxy.  Only the final
   CoA server (i.e NAS) can make a decision on which attributes are
   mandatory and which are not.

   Instead, we say that for a CoA proxy, all attributes MUST NOT be
   treated as mandatory.  Proxies implementing this specification MUST
   perform proxying based on Operator-Name.  Other schemes are possible,
   but are not discussed here.  Proxies SHOULD forward all packets as-
   is, with minimal changes.

   We note that some NAS implementations currently treat signaling
   attributes as mandatory.  For example, some NAS implementations will
   NAK any CoA packet that contains a Proxy-State attribute.  While this
   behavior is based on a straightforward reading of the above text, it
   causes problems in practice.

   We update Section 2.3 of [RFC5176] to say that in CoA-Request and
   Disconnect-Request packets, the NAS MUST NOT treat as mandatory any
   attribute which is known to not affect the users session.  For
   example, the Proxy-State attribute.  Proxy-State is an attribute used
   for proxy-to-proxy signaling.  It cannot affect the user's session,
   and therefore Proxy-State (and similar attributes) MUST be ignored by
   the NAS.

   When Operator-Name and/or Operator-NAS-Identifier are received by a
   proxy, the proxy MUST pass those attributes through unchanged.  This
   requirement applies to all proxies, including ones that forward any

DeKok, Alan                 Proposed Standard                  [Page 16]
INTERNET-DRAFT  Dynamic Authorization Proxying in RADIUS 22 January 2019

   or all of Access-Request, Accounting-Request, CoA-Request, and
   Disconnect-Request packets.

   All attributes added by a RADIUS proxy when sending packets from the
   Visited Network to the Home Network Network MUST be removed by the
   corresponding CoA proxy from packets traversing the reverse path.
   That is, any attribute editing that is done on the "forward" path
   MUST be undone on the "reverse" path.

   The result is that a NAS will only ever receive CoA packets that
   either contain attributes sent by the NAS to it's local RADIUS
   server, or contain attributes that are sent by the Home Server in
   order to perform a change of authorization.

   Finally, we extend the above requirement not only to Operator-Name
   and Operator-NAS-Identifier, but also to any future attributes that
   are added for proxy-to-proxy signaling.

5.  Functionality

   This section describes how the two attributes work together to permit
   CoA proxying.

5.1.  User Login
   In this scenario, we follow a roaming user who is attempting to log
   in to a Visited Network.  The login attempt is done via a NAS in the
   Visited Network.  That NAS will send an Access-Request packet to the
   visited RADIUS server.  The visited RADIUS server will see that the
   user is roaming, and will add an Operator-Name attribute, with value
   "1" followed by it's own realm name.  e.g. "1example.com".  The
   visited RADIUS server MAY also add an Operator-NAS-Identifier.  The
   NAS identification attributes are also edited, as required by Section
   3.4, above.

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

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

5.2.  CoA Proxying

   At some later point in time, the Home Server determines that a user
   session should have its authorization changed, or be disconnected.
   The Home Server looks up the Operator-Name and Operator-NAS-

DeKok, Alan                 Proposed Standard                  [Page 17]
INTERNET-DRAFT  Dynamic Authorization Proxying in RADIUS 22 January 2019

   Identifer, along with other user session identifiers as described in
   [RFC5176].  The Home Server then looks up the realm from the
   Operator-Name attribute in the logical AAA routing table, in order to
   find the "next hop" CoA server for that realm (that may be a proxy).
   The CoA request is then sent to that CoA server.

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

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

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

   The Operator-Name and Operator-NAS-Identifer attributes are then
   removed from the packet; one of NAS-IP-Address, or NAS-IPv6-Address,
   or NAS-Identifier is added to the packet; and the packet is then sent
   to the CoA server.

   If no CoA server can be found, the Visited Network return a CoA-NAK
   with Error-Cause 403 (NAS Identification Mismatch).

   Any response from the CoA server (NAS) is returned to the Home
   Network, via the normal method of returning responses to requests.

6.  Security Considerations

   This specification incorporates by reference the Section 11 of
   [RFC6929].  In short, RADIUS has many known issues which are
   discussed in detail there, and which do not need to be repeated here.

   This specification adds one new attribute, and defines new behavior
   for RADIUS proxying.  As this behavior mirrors existing RADIUS
   proxying, we do not believe that it introduces any new security
   issues.  We note, however, that RADIUS proxying has a series of
   inherent security issues.

DeKok, Alan                 Proposed Standard                  [Page 18]
INTERNET-DRAFT  Dynamic Authorization Proxying in RADIUS 22 January 2019

6.1.  RADIUS Security and Proxies

   The requirement that packets be signed with a shared secret means
   that a CoA packet can only be received from a trusted party.  Or
   transitively, received from a third party via a trusted party.  This
   security provision of the base RADIUS protocol makes it impossible
   for untrusted parties to affect the user's session.

   When RADIUS proxying is performed, all packets are signed on a hop-
   by-hop basis.  Any intermediate proxy can therefore forge packets,
   replay packets, or modify the contents of any packets entirely
   without detection.  As a result, the secure operation of such a
   system depends largely on trust, instead of on technical means.

   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

DeKok, Alan                 Proposed Standard                  [Page 19]
INTERNET-DRAFT  Dynamic Authorization Proxying in RADIUS 22 January 2019

   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

   IANA is instructed to allocate one new RADIUS attribute, as per
   Section 3.3, above.  The Operator-NAS-Identifier attribute is to be
   allocated from the RADIUS Attribute Types registry as follows:

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

8.  References

8.1.  Normative References

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

[RFC2865]
     Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authen-
     tication 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]
     Chiba, M. et al, "Dynamic Authorization Extensions to Remote
     Authentication Dial In User Service (RADIUS)", RFC 5176, January

DeKok, Alan                 Proposed Standard                  [Page 20]
INTERNET-DRAFT  Dynamic Authorization Proxying in RADIUS 22 January 2019

     2008, <http://www.rfc-editor.org/info/rfc5176>.

[RFC5580]
     Tschofenig H., Ed. "Carrying Location Objects in RADIUS and Diame-
     ter", RFC 5580, August 2009,  <http://www.rfc-edi-
     tor.org/info/rfc5580>.

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

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

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

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

8.2.  Informative References

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

Authors' Addresses

   Alan DeKok
   The FreeRADIUS Server Project

   Email: aland@freeradius.org

   Jouni Korhonen

   EMail: jouni.nospam@gmail.com

DeKok, Alan                 Proposed Standard                  [Page 21]