[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 draft-ietf-radext-coa-proxy

Network Working Group                                        DeKok, Alan
INTERNET-DRAFT                                                FreeRADIUS
Updates: 5176                                                J. Korhonen
Category: Standards Track                         Nokia Siemens Networks
3 July 2014

                   Dynamic Authorization Proxying in
      Remote Authorization Dial-In User Service Protocol (RADIUS)


   RFC 5176 defines Change of Authorization (CoA) and Disconnect Message
   (DM) behavior for RADIUS.  Section 3.1 of that document suggests that
   proxying these messages is possible, but gives no guidance as to how
   that is done.  This specification corrects that ommission.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on January 4, 2015.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal

DeKok, Alan                   Informationl                      [Page 1]

INTERNET-DRAFT  Dynamic Authorization Proxying in RADIUS     3 July 2014

   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info/) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

DeKok, Alan                   Informationl                      [Page 2]

INTERNET-DRAFT  Dynamic Authorization Proxying in RADIUS     3 July 2014

Table of Contents

1.  Introduction .............................................    4
   1.1.  Terminology .........................................    4
   1.2.  Requirements Language ...............................    4
2.  Problem Statement ........................................    5
   2.1.  Typical RADIUS Proxying .............................    5
   2.2.  CoA Processing ......................................    5
   2.3.  Failure of CoA Proxying .............................    5
3.  How to Perform CoA Proxying ..............................    6
   3.1.  Operator-NAS-Identifier .............................    6
4.  Functionality ............................................    7
   4.1.  User Login ..........................................    7
   4.2.  CoA Proxing .........................................    8
5.  Security Considerations ..................................    8
6.  IANA Considerations ......................................    9
7.  References ...............................................    9
   7.1.  Normative References ................................    9
   7.2.  Informative References ..............................    9

DeKok, Alan                   Informationl                      [Page 3]

INTERNET-DRAFT  Dynamic Authorization Proxying in RADIUS     3 July 2014

1.  Introduction

   RFC 5176 [RFC5176] defines Change of Authorization (CoA) and
   Disconnect Message (DM) behavior for RADIUS.  Section 3.1 of that
   document suggests that proxying these messages is possible, but gives
   no guidance as to how that is done.  This ommission means that
   proxying of CoA packets is, in practice, impossible.

   We correct that ommission here.

1.1.  Terminology

   This document frequently uses the following terms:

   Network Access Identifier

      The Network Access Identifier (NAI) is the user identity submitted
      by the client during network access authentication.  The purpose
      of the NAI is to identify the user as well as to assist in the
      routing of the authentication request.  Please note that the NAI
      may not necessarily be the same as the user's email address or the
      user identity submitted in an application layer authentication.

   Network Access Server

      The Network Access Server (NAS) is the device that clients connect
      to in order to get access to the network.  In PPTP terminology,
      this is referred to as the PPTP Access Concentrator (PAC), and in
      L2TP terminology, it is referred to as the L2TP Access
      Concentrator (LAC).  In IEEE 802.11, it is referred to as an
      Access Point.

   Home Network

      The home network of a user.

   Visited Network

      The network which is accessed by a user, when that network is not
      their home network.

1.2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

DeKok, Alan                   Informationl                      [Page 4]

INTERNET-DRAFT  Dynamic Authorization Proxying in RADIUS     3 July 2014

2.  Problem Statement

   This section describes how RADIUS proxying works, how CoA packets
   work, and why CoA proxying does not work in the current system.

2.1.  Typical RADIUS Proxying

   When a RADIUS server proxies an Access-Request packet, it typically
   does so based on the contents of the User-Name attribute, which
   contains Network Access Identifier [NAI].  Other methods are
   possible, but we restrict ourselves to the most common usage.

   The proxy server looks up the "Realm" portion of the NAI in a logical
   AAA routing table, as described in Section 3 of [NAI].  The entry in
   that table is the "next hop" to which the packet is sent.  This "next
   hop" may be another proxy, or it may be the home server for that

   The "next hop" may perform the same Realm lookup, and the proxy the
   packet also.  Alternatively, if the "next hop" is the Home Server for
   that realm, it will typically authenticate the user, and respond with
   an Access-Accept, Access-Reject, or Access-Challenge.

   The response can be returned from the home server to the visited
   network, because each proxy server tracks the requests it has
   forwarded.  When a response packet is by the proxy, it is matched to
   an incoming request, which lets the proxy forward the response to the
   source of the original request.

2.2.  CoA Processing

   [RFC5176] describes how CoA clients (often RADIUS servers) will send
   packets to CoA servers (often RADIUS clients).  In typical use, CoA
   packets are sent within one network.  That is, within the same
   "Realm".  When used within one "Realm", there is only one "hop" for
   packets to take, so no proxying is necessary.

2.3.  Failure of CoA Proxying

   In the case of CoA proxying, the above scenarios fail.  CoA packets
   may be sent minutes to hours after reception of the original Access-
   Request.  In addition, the packet codes are different, so there is no
   way to match a CoA-Request packet to a particular Access-Request
   packet.  There is therefore no "reverse path" for the CoA packet to

   As with Access-Request proxying, CoA proxying can be done done
   between Realms.  There exists potentially multiple "hops" for packets

DeKok, Alan                   Informationl                      [Page 5]

INTERNET-DRAFT  Dynamic Authorization Proxying in RADIUS     3 July 2014

   to follow.  Packets cannot be forwarded to the Visited Network, based
   on the contents of the User-Name attribute, as that contains the
   Realm of the Home Network.

   The conclusion is therefore that CoA proxying is impossible when
   using behavior defined in [RFC5176].  There is, however a solution.

3.  How to Perform CoA Proxying

   The solution is seen in the Operator-Name attribute defined in
   [RFC5580], Section 4.1.  We repeat portions of that definition here
   for clarity:

      This attribute carries the operator namespace identifier and the
      operator name.  The operator name is combined with the namespace
      identifier to uniquely identify the owner of an access network.

   Followed by a description of the REALM namespace:

      REALM ('1' (0x31)):

      The REALM operator namespace can be used to indicate operator
      names based on any registered domain name.  Such names are
      required to be unique, and the rights to use a given realm name
      are obtained coincident with acquiring the rights to use a
      particular Fully Qualified Domain Name (FQDN). ...

   In short, the Operator-Name attribute contains the an ASCII "1",
   followed by the Realm of the Visited Network.  e.g. for the
   "example.com" realm, the Operator-Name attribute contains the text
   "1example.com".  This information is precisely what we need to
   perform CoA proxying.

   The only missing information is which NAS is managing the user.  We
   may expect that the Visited Network will track this information, but
   there is no requirement for it to do so.  We therefore need an
   additional attribute to contain this information.

3.1.  Operator-NAS-Identifier

   The Operator-NAS-Identifier attribute contains opaque information
   identifying a NAS.  It MAY appear in the following packets: Access-
   Request, Accounting-Request, CoA-Request, DM-Request.  Operator-NAS-
   Identifier MUST NOT 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.

DeKok, Alan                   Informationl                      [Page 6]

INTERNET-DRAFT  Dynamic Authorization Proxying in RADIUS     3 July 2014

   Operator-NAS-Identifier MUST NOT occur more than once in a packet.

   When an Operator-NAS-Identifer attribute is added by a proxy in a
   Visited Network, the following attributes MUST be deleted: NAS-IP-
   Address, NAS-IPv6-Address, NAS-Identifier.  The proxy MUST then add a
   NAS-Identifier attribute, in order satisfy the requirments of Secton
   4.1 of [RFC2865], and of [RFC2866].  We suggest that the contents of
   the NAS-Identifier be the Realm name of the Visited Network.


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


      TBD.  To be assigned by IANA


      TBD.  Depends on IANA allocation.

      Implementations supporting this attribute MUST be able to handle
      between one (1) and twenty (20) octets of data.  Implementations
      creating an Operator-NAS-Identifier SHOULD NOT create attributes
      with more than twenty octets of data.  A twenty octet string is
      more than sufficient to individually address all of the NASes on
      the planet.

   Data Type

      string.  See [DATA] Section 2.6 for a definition.


      The contents of this attribute are an opaque token interpretable
      only by the Visited Network.  The attribute MUST NOT contain any
      secret or private information.

4.  Functionality

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

4.1.  User Login

   The user logs in.  When a Visited Network sees that the packet is
   proxied, it adds an Operator-Name with "1" followed by it's own realm

DeKok, Alan                   Informationl                      [Page 7]

INTERNET-DRAFT  Dynamic Authorization Proxying in RADIUS     3 July 2014

   name.  It MAY also add an Operator-NAS-Identifier.

   The proxies then forward the packet.  They MUST NOT delete or modify
   Operator-Name and/or Operator-NAS-Identifier.

   The Home Server records both Operator-Name and Operator-NAS-Identfier
   along with other information about the users session.

4.2.  CoA Proxing

   When the Home Server decides to disconnect a user, it looks up the
   Operator-Name and Operator-NAS-Identifer, along with other user
   session identifiers as described in [RFC5176].  It then looks up the
   Operator-Name in the logical AAA routing table to find the CoA server
   for that realm (which may be a proxy).  The CoA-Request is then sent
   to that 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 returns a
   CoA-NAK with Error-Cause 502 (Request Not Routable).

   The Visited Network recieves the CoA-Request packet, and uses the
   Operator-NAS-Identifier attribute to determine which local CoA server
   (i.e. NAS) the packet should be sent to.

   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

5.  Security Considerations

   This specification incorporates by reference the [RFC6929] Section
   11.  In short, RADIUS has known issues which are discussed there.

   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

   Operator-NAS-Identifier should remain secure.  We don't say how.

DeKok, Alan                   Informationl                      [Page 8]

INTERNET-DRAFT  Dynamic Authorization Proxying in RADIUS     3 July 2014

6.  IANA Considerations

   IANA is instructed to allocated one new RADIUS attribute, as per
   Section 3.1, above.

7.  References

7.1.  Normative References

     Bradner, S., "Key words for use in RFCs to Indicate Requirement
     Levels", RFC 2119, March, 1997.

     Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
     Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.

     Tschofenig H., Ed. "Carrying Location Objects in RADIUS and
     Diameter", RFC 5580, August 2009.

     DeKok A. and Lior, A., "Remote Authentication Dial-In User Service
     (RADIUS) Protocol Extensions", RFC 6929, April 2013.

     DeKok A., "The Network Access Identifier", draft-ietf-radext-
     nai-06.txt, June 2013.

     DeKok A., "Data Types in the Remote Authentication Dial-In User
     Service Protocol (RADIUS)", draft-dekok-radext-datatypes-04.txt,
     Juen 2014

7.2.  Informative References

     Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.

     Chiba, M. et al, "Dynamic Authorization Extensions to Remote
     Authentication Dial In User Service (RADIUS)", RFC 5176, January



DeKok, Alan                   Informationl                      [Page 9]

INTERNET-DRAFT  Dynamic Authorization Proxying in RADIUS     3 July 2014

Authors' Addresses

   Alan DeKok
   The FreeRADIUS Server Project

   Email: aland@freeradius.org

   Jouni Korhonen
   Nokia Siemens Networks
   Linnoitustie 6
   Espoo  FI-02600

   EMail: jouni.nospam@gmail.com

DeKok, Alan                   Informationl                     [Page 10]

Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/