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

Versions: (draft-dekok-radext-coa-proxy) 00 01

Network Working Group                                        DeKok, Alan
INTERNET-DRAFT                                                FreeRADIUS
Updates: 5176                                                J. Korhonen
Category: Standards Track                         Nokia Siemens Networks
<draft-ietf-radext-coa-proxy-01.txt>
8 July 2016


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

Abstract

   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 omission.

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-
   Drafts.

   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
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on February 8, 2016.

Copyright Notice

   Copyright (c) 2016 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                   Informational                     [Page 1]


INTERNET-DRAFT  Dynamic Authorization Proxying in RADIUS     8 July 2016


   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                   Informational                     [Page 2]


INTERNET-DRAFT  Dynamic Authorization Proxying in RADIUS     8 July 2016


Table of Contents

1.  Introduction .............................................    4
   1.1.  Terminology .........................................    4
   1.2.  Requirements Language ...............................    5
2.  Problem Statement ........................................    6
   2.1.  Typical RADIUS Proxying .............................    6
   2.2.  CoA Processing ......................................    6
   2.3.  Failure of CoA Proxying .............................    7
3.  How to Perform CoA Proxying ..............................    7
   3.1.  Operator-Name in Access-Request and Accounting-Reques    8
   3.2.  Operator-Name in CoA-Request and Disconnect-Request p    8
   3.3.  Operator-NAS-Identifier .............................    9
4.  Requirements .............................................   10
   4.1.  Requirements on Home Servers ........................   10
   4.2.  Requirements on Visited Networks ....................   11
   4.3.  Requirements on Proxies .............................   11
      4.3.1.  Security Requirements on Proxies ...............   11
      4.3.2.  Filtering Requirements on Proxies ..............   12
5.  Functionality ............................................   13
   5.1.  User Login ..........................................   13
   5.2.  CoA Proxing .........................................   13
6.  Security Considerations ..................................   14
7.  IANA Considerations ......................................   14
8.  References ...............................................   14
   8.1.  Normative References ................................   14
   8.2.  Informative References ..............................   15
























DeKok, Alan                   Informational                     [Page 3]


INTERNET-DRAFT  Dynamic Authorization Proxying in RADIUS     8 July 2016


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 by explaining how an existing RADIUS
   attribute, Operator-Name ( Section 4.1 of [RFC5580]), can be used to
   record the visited network for a particular session.  We then explain
   how that attribute can be used by CoA proxies to route packets
   "backwards" through a RADIUS proxy chain.  We introduce a new
   attribute; Operator-NAS-Identifier, and show how this attribute can
   increase privacy about the internal implementation of the visited
   netowkr.

   We conclude with a discussion of the security implications of the
   design, and show how they are acceptable.

1.1.  Terminology

   This document frequently uses the following terms:

   CoA

      Change of Authorization, e.g. CoA-Request, or CoA-ACK, or CoA-NAK,
      as defined in [RFC5176].  That specification also defines
      Disconnect-Request, Disconnect-ACK, and Disconnect-NAK.  For
      simplicity here, where we use "CoA", we mean a generic "CoA-
      Request or Disconnect-Request" packet.  We use "CoA-Request" or
      "Disconnect-Request" to refer to the specific packet types.

   Network Access Identifier

      The Network Access Identifier (NAI) 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



DeKok, Alan                   Informational                     [Page 4]


INTERNET-DRAFT  Dynamic Authorization Proxying in RADIUS     8 July 2016


      Concentrator (LAC).  In IEEE 802.11, it is referred to as an
      Access Point.

   Home Network

      The network which holds the authentication credentials for a user.

   Visited Network

      A network other than the home network, where the user attempts to
      gain network access.  The Visited Network typically has a
      relationship with the Home Network, and can ask the Home Network
      is the user is authentic (or not).


1.2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].































DeKok, Alan                   Informational                     [Page 5]


INTERNET-DRAFT  Dynamic Authorization Proxying in RADIUS     8 July 2016


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 [RFC7542].  Other methods are
   possible, but we restrict ourselves to this usage, as it is the most
   common one.

   The proxy server looks up the "Realm" portion of the NAI in a logical
   AAA routing table, as described in Section 3 of [RFC7542].  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 realm.

   If the "next hop" is a proxy, it will perform the same Realm lookup,
   and then proxy the packet.  Alternatively, if the "next hop" is the
   Home Server for that realm, it will try to authenticate the user, and
   respond with an Access-Accept, Access-Reject, or Access-Challenge.

   The RADIUS client will match the response packet to an outstanding
   request.  If the client is part of a proxy, it will then proxy that
   response packet in turn to the system which 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 /
   response packets, but stateless with respect to user sessions.  Once
   a reply has been recieved by the proxy, it can discard all
   information about the user.

   The same proxy method is used for Accounting-Request packets.  The
   combination of the two methods allows proxies to connect Visited
   Networks to Home Networks for all AAA purposes.

2.2.  CoA Processing

   [RFC5176] describes how CoA clients send packets to CoA servers.  We
   note that system comprising the CoA client is typically co-located
   with, or the same as, the RADIUS server.  Similarly, the CoA server
   is a system that is either co-located with, or the same as, the
   RADIUS client.

   In the case of packets sent inside of one network, the source and



DeKok, Alan                   Informational                     [Page 6]


INTERNET-DRAFT  Dynamic Authorization Proxying in RADIUS     8 July 2016


   destination of CoA packets is locally determined.  There is thus no
   need for standardization of that process, as networks are free to
   send CoA packets whenever they want, for whatever reason they want.

2.3.  Failure of CoA Proxying

   The situation is more complicated when multiple networks are
   involved.  [RFC5176] suggests that CoA proxying is permitted, but
   makes no suggestions for how it should be done.

   If proxies tracked user sessions, it might be possible for a proxy to
   match an incoming CoA-Request to a user session, and then to proxy
   that packet to the RADIUS client which originated the Access-Request
   for that sessions.

   There are many problems with such a scenario.  The CoA server may, in
   fact, not be co-located with the RADIUS client.  The RADIUS client
   may be down, but there may be a different CoA server which could
   accept 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 "session
   identification attributes", which makes it impossible for a proxy to
   determine if a CoA packet matches a particular user session.

   The result is that CoA proxying cannot be performed when using the
   behavior defined in [RFC5176].

3.  How to Perform CoA Proxying

   The solution to the above problem is to use 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",



DeKok, Alan                   Informational                     [Page 7]


INTERNET-DRAFT  Dynamic Authorization Proxying in RADIUS     8 July 2016


   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.

3.1.  Operator-Name in Access-Request and Accounting-Request packets

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

   Visited Networks MUST use a consistent value for Operator-Name for
   one user session.  That is, sending "1example.com" in an Access-
   Request packet, and "1example.org" in an Accounting-Request packet
   for that same session is forbidden.

   Proxies which record user session information SHOULD also record
   Operator-Name.  Proxies which do not record user session information
   SHOULD NOT record Operator-Name.

   Home Networks SHOULD record Operator-Name along with other
   information about user sessions.  Home Networks which expect to send
   CoA packets to Visited Networks MUST record Operator-Name for each
   user session which originates from a Visited Network.

   Networks which contain both the RADIUS client and RADIUS server do
   not need to record or track Operator-Name.

3.2.  Operator-Name in CoA-Request and Disconnect-Request packets

   When a Home Network wishes to send a CoA-Request or Disconnect-
   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
   value which was recorded earlier for that user session.

   The Home Network MUST lookup the realm from the Operator-Name in a
   logical "realm routing table", as discussed in [RFC7542] Section 3.
   In this case, the destination of the packet is not a RADIUS server,
   but a CoA server.

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



DeKok, Alan                   Informational                     [Page 8]


INTERNET-DRAFT  Dynamic Authorization Proxying in RADIUS     8 July 2016


   Proxies which receive the CoA packet MUST look up the realm from the
   Operator-Name in a logical "realm routing table", as with Home
   Servers, above.  This process continues with any additional proxies
   until the packet reaches the Visited Network.

   The Visited Network can then send the CoA packet to the NAS, and
   return any response packet back up the proxy chain to the Home
   Server.

   Networks which contain both the CoA client and CoA server do not need
   to record or track Operator-Name.

3.3.  Operator-NAS-Identifier

   The process described in the previous section allows for CoA
   proxying, but it does not support privacy for Visited Networks.  That
   is, all "internal" information about the Visited Network is public.
   This information includes NAS-Identifier, NAS-IP-Address, NAS-
   IPv6-Address, etc.  We belive that the internals of the Visited
   Network should be opaque to third parties.

   In addition, we will see that privacy provisions can have a positive
   impact on the security of the system.

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

   An Operator-NAS-Identifer attribute SHOULD be added to an Access-
   Request or Accounting-Request packet by a Visited Network just before
   proxying a packet to an external RADIUS server.  When the Operator-
   NAS-Identifer attribute is added to a packet, 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 requirements of Section 4.1 of [RFC2865], and of
   [RFC2866].

   We suggest that the contents of the NAS-Identifier be the Realm name
   of the Visited Network.  That is, for everyone outside of the Visited
   Network, the identity of the NAS is the Visited Network.  For the
   Visited Network, the identity of the NAS is private information,
   which is opaque to everyone else.



DeKok, Alan                   Informational                     [Page 9]


INTERNET-DRAFT  Dynamic Authorization Proxying in RADIUS     8 July 2016


   Description

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

   Type

      TBD.  To be assigned by IANA

   Length

      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.

   Value

      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.  Requirements


4.1.  Requirements on Home Servers

   A Home Server MUST NOT send CoA packets for users who are not part of
   its realm.  The provisions of the next few sections describe how
   other participants in the RADIUS ecosystem can enforce this
   requirement.

   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 any
   Operator-NAS-Identifier it has recorded for that session.







DeKok, Alan                   Informational                    [Page 10]


INTERNET-DRAFT  Dynamic Authorization Proxying in RADIUS     8 July 2016


4.2.  Requirements on Visited Networks

   A Visited Network which receives a proxied CoA packet MUST perform
   all of the checks discussed above for proxies.  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.

   Due to the requirements of Section 2.3 of [RFC5176], a Visited
   Network MUST remove Operator-Name and Operator-NAS-Identifier from
   any CoA-Request or Disconnect-Request packet prior to proxying that
   packet to a CoA server.  This requirement is phrase more generically
   below, in Section XX.

   While a Visited Network may create an Operator-NAS-Identifier via
   many methods.  The value SHOULD be cryptographically strong.  It
   SHOULD be verifiable by the Visited Network, without tracking every
   single user session.

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 that these systems are co-located.

4.3.1.  Security Requirements on Proxies

   Section 6.1 of [RFC5176] has some security requirements on proxies
   which 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 change that requirement to a proxy MUST perform a "reverse path
   forwarding" (RPF) check to verify that a Disconnect-Request or CoA-
   Request originates from an authorized Dynamic Authorization Client.
   Without this change, a proxy may forward forged packets, and thus
   contribute to the forgery problem instead of preventing it.

   Proxies which 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



DeKok, Alan                   Informational                    [Page 11]


INTERNET-DRAFT  Dynamic Authorization Proxying in RADIUS     8 July 2016


   CoA-NAK or Disconnect-NAK packet, which contains an Error-Cause
   attribute having value 503 ("Session Context Not Found").

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

   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
   substantiall different from changing (or refusing to connect) a user
   session during the initial process of authentiction.

   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.

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.  Instead, we
   say that for a CoA proxy, all attributes MUST NOT be treated as
   mandatory.  Proxies SHOULD perform proxying based on Operator-Name,
   but other schemes are possible (though not discussed here).  Proxies
   SHOULD forward all packets as-is, with minimal changes.  Only the
   final CoA server (i.e RADIUS 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
   proxy, the proxy MUST pass those attributes through unchanged.

   All attributes added by a RADIUS proxy when sending packets from the
   Visited Network to the Home Network Network MUST be removed by the



DeKok, Alan                   Informational                    [Page 12]


INTERNET-DRAFT  Dynamic Authorization Proxying in RADIUS     8 July 2016


   corresponding CoA proxy from packets which travel the reverse path.
   The result is that a NAS will only ever receive CoA packets which
   contain either attributes sent by the NAS to the RADIUS server, or
   attributes which are required to perform a change of authorization.

   We note that the above requirement applies not only to Operator-Name
   and Operator-NAS-Identifier, but also to any future attributes which
   are added by a RADIUS proxy.

   In short, proxies SHOULD behave much like a CoA server, and where
   possible, perform many of the same validations done by a CoA server.

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 attempting authenticastion
   in a visited network.  The login attempt is done via a visited NAS.
   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 proxy the authentication request to an upstream server.  That
   server may be the home server for the user, or it may be another
   proxy.

   The visited RADIUS server should add an Operator-Name attribute, with
   value "1" followed by it's own realm name.  e.g. "1example.com".
   Where the visited network has multiple realms, it MUST choose a realm
   name which permits packets to be routed back to itself.  The visited
   RADIUS server MAY also add an Operator-NAS-Identifier as discussed
   below.

   The upstream proxy or proxies will then forward the packet to the
   home server.  Intermediate proxies MUST NOT modify the contents of,
   or delete the Operator-Name or Operator-NAS-Identifier attributes.

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

5.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



DeKok, Alan                   Informational                    [Page 13]


INTERNET-DRAFT  Dynamic Authorization Proxying in RADIUS     8 July 2016


   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
   Network.

6.  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
   issues.

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

7.  IANA Considerations

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

8.  References

8.1.  Normative References

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

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



DeKok, Alan                   Informational                    [Page 14]


INTERNET-DRAFT  Dynamic Authorization Proxying in RADIUS     8 July 2016


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

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

[RFC7542]
     DeKok A., "The Network Access Identifier", RFC 7542, May 2015.

[DATA]
     DeKok A., "Data Types in the Remote Authentication Dial-In User
     Service Protocol (RADIUS)", draft-ietf-radext-datatypes-02.txt,
     November 2015

8.2.  Informative References

[RFC2866]
     Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.

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

Acknowledgments

   Stuff

Authors' Addresses

   Alan DeKok
   The FreeRADIUS Server Project

   Email: aland@freeradius.org

   Jouni Korhonen
   Broadcom Corporation
   3151 Zanker Road
   San Jose, California  95134
   United States

   EMail: jouni.nospam@gmail.com







DeKok, Alan                   Informational                    [Page 15]


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