Skip to main content

Correlating requests and replies in the Remote Authentication Dial In User Service (RADIUS) Protocol via the Request Authenticator.
draft-dekok-radext-request-authenticator-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Author Alan DeKok
Last updated 2017-04-28 (Latest revision 2017-04-24)
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-dekok-radext-request-authenticator-01
Network Working Group                                         Alan DeKok
INTERNET-DRAFT                                                FreeRADIUS
Category: Proposed Standard
Updates: 2885
<draft-dekok-radext-request-authenticator-01.txt>
Expires: October 28, 2016
28 April 2017

                Correlating requests and replies in the
      Remote Authentication Dial In User Service (RADIUS) Protocol
                     via the Request Authenticator.
            draft-dekok-radext-request-authenticator-01.txt

Abstract

   RADIUS contains a one-octet Identifier field which is used to
   correlate requests and replies.  This field limits the number of
   outstanding requests to 256.  Experience shows that this limitation
   is problematic for high load systems.  This document proposes to use
   the Request Authenticator field as an additional unique identifier.
   The replies can then be correlated to requests by copying the Request
   Authenticator from the request to a new attribute in the response,
   called the Original-Request-Authenticator.

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 November 18, 2010.

DeKok, Alan                  Standards Track                    [Page 1]
INTERNET-DRAFT         Identifying RADIUS packets.         28 April 2017

Copyright Notice

   Copyright (c) 2010 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
   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.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

DeKok, Alan                  Standards Track                    [Page 2]
INTERNET-DRAFT         Identifying RADIUS packets.         28 April 2017

Table of Contents

   9.1. ......................................................    3
1.  Introduction .............................................    4
   1.1.  Limitations and Requirements ........................    4
   1.2.  Outline of the document .............................    6
   1.3.  Terminology .........................................    6
   1.4.  Requirements Language ...............................    6
2.  Overview .................................................    7
3.  Signaling via Status-Server ..............................    8
   3.1.  Static Configuration ................................    9
4.  Original-Request-Authenticator Attribute .................   10
5.  Transport Considerations .................................   11
   5.1.  UDP .................................................   11
   5.2.  TCP .................................................   12
   5.3.  Dynamic Discovery ...................................   12
   5.4.  Connection Issues ...................................   13
6.  System Considerations ....................................   13
   6.1.  Client Considerations ...............................   13
   6.2.  Server Considerations ...............................   14
   6.3.  Proxy Considerations ................................   14
7.  IANA Considerations ......................................   15
8.  Security Considerations ..................................   15
9.  Normative References .....................................   15
9.1. .........................................................   16

DeKok, Alan                  Standards Track                    [Page 3]
INTERNET-DRAFT         Identifying RADIUS packets.         28 April 2017

1.  Introduction

   The Remote Authentication Dial In User Service (RADIUS) protocol
   contains an Identifier field, defined in [RFC2865] Section 5 as:

      The Identifier field is one octet, and aids in matching requests
      and replies.  The RADIUS server can detect a duplicate request if
      it has the same client source IP address and source UDP port and
      Identifier within a short span of time.

   The small size of the field allows for only 256 outstanding requests.
   If a client requires more than 256 packets to be outstanding to the
   RADIUS server, it must open a new source port.

   This limitation has been adequate for low-load RADIUS systems.  But
   it is a problem in practice for high-load systems.  Opening new
   sockets can be expensive for resource limited clients, and is
   generally unnecessary in other UDP protocols.

   For very high load systems, it would be good to allow RADIUS clients
   to "fill the pipe" with data.  The problem is that RADIUS packets
   tend to be small, and RADIUS over UDP can reach the packet per second
   limit of the underlying network, which is usually much lower than the
   rated bandwidth of the link.

   We could use RADIUS over TCP [RFC6614], and rely on the network stack
   to use all available link bandwidth.  However, the one-octet limit
   for the Identifier field means that a RADIUS client may only send 20K
   of data (in the low end), before that connection is "full", and the
   client must use another one.

1.1.  Limitations and Requirements

   Extending RADIUS is an subject fraught with difficulties.  Any change
   is subject to many requirements and limitations.  We note some here.

   * this specification makes no change to the RADIUS packet format

   * this specification makes no change to RADIUS security

   * this specification adds no new RADIUS data types

   * all existing RADIUS packet encoders / decoders will accept as valid
     all packets generated by this specification

   * this specification adds one attribute to the RADIUS Attribute
     registry.  That attribute uses a standard data type.

DeKok, Alan                  Standards Track                    [Page 4]
INTERNET-DRAFT         Identifying RADIUS packets.         28 April 2017

   * due to negotiation of capabilities, implementations of this
     specification are fully compatible with all existing RADIUS
     implementations.

   * this specification changes the way clients and server internally
     match requests and responses.

   The goal of this specification was to create a standard which would
   not fundamentally change RADIUS, but would instead allow it to be
   extended in minor ways.

   We also note that any change to RADIUS should explain why we should
   not just use Diameter instead.  As noted on the RADEXT working group
   mailing list [PATCH], an implementation of similar functionality for
   a different specification is less than 200 lines of C code.  That
   patch includes capability negotiation via Status-Server, and full
   client / server / proxy support for the specification.

   We assume that this specification requires a similar level of code
   changes in clients and servers.  Barring evidence to the contrary,
   this assumption seems reasonable.

   We suggest that it is simpler for implementors to make minor changes
   to their RADIUS systens than it is to implement a full Diameter
   stack.  This reality should be a major consideration when creating
   new specifications.

   There are alternatives to this proposal.  [RFC2865] Section 5 says:

      NAS needs more than 256 IDs for outstanding requests, it MAY use
      additional source ports to send requests from, and keep track of
      IDs for each source port.  This allows up to 16 million or so
      outstanding requests at one time to a single server

   This suggestion has been widely implemented.  However, practice shows
   that the number of open ports has a practical limitation much lower
   than 65535.  This limitation is due both to ports being used by other
   applications on the same system, and application-specific
   complexities related to opening thousands of ports.

   There are also transport issues, where the 256 ID limit means due to
   the small amount of traffic on each connection, TCP transport is
   unable to obtain the full benefits of TCP.  Instead, RADIUS over TCP
   can have the the behavior of the worst of both UDP and TCP.  This
   issue is discussed in more detail in Section X, below.

   As a result, we propose minor changes to RADIUS, instead of
   suggesting that implementors move to Diameter.

DeKok, Alan                  Standards Track                    [Page 5]
INTERNET-DRAFT         Identifying RADIUS packets.         28 April 2017

1.2.  Outline of the document

   The document gives a high level overview of proposal.  It then
   describes how the functionality is signaled in a Status-Server
   [RFC5997] It then defines the Original-Request-Authenticator
   attribute.  It then describes how this change to RADIUS affects each
   type of packet (ordered by Code).  Finally, it describes how the
   change affects transports such as UDP, TCP, and TLS.

1.3.  Terminology

   This document uses the following terms:

Key  The combination of (src/dst IP/port, Code, and Identifier) used to
     correlate request / response packets.

Network Access Server (NAS)
     The device providing access to the network.  Also known as the
     Authenticator (in IEEE 802.1X terminology) or RADIUS client.

RADIUS Proxy
     In order to provide for the routing of RADIUS authentication and
     accounting requests, a RADIUS proxy can be employed. To the NAS,
     the RADIUS proxy appears to act as a RADIUS server, and to the
     RADIUS server, the proxy appears to act as a RADIUS client.

1.4.  Requirements Language

   In this document, several words are used to signify the requirements
   of the specification.  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                  Standards Track                    [Page 6]
INTERNET-DRAFT         Identifying RADIUS packets.         28 April 2017

2.  Overview

   We propose to use the Request Authenticator field as an additional
   unique identifier.  Subject to certain limitations outlined below,
   the Request Authenticator can be broadly treated as being temporally
   and globally unique.  This uniqueness is what allows it to be used as
   a packet identifier.

   Further, clients are already required to store the Request
   Authenticator for all packets, as it is used to verify the Response
   Authenticator in the response packet.

   When a client receives a response, it uses the network information
   (src/dst IP/port), along with the Code and Identifier field, to find
   the original request.  For example, [RFC2865] Section 4.2 has the
   following text for Access-Accept responses:

      On reception of an Access-Accept, the Identifier field is matched
      with a pending Access-Request.  The Response Authenticator field
      MUST contain the correct response for the pending Access-Request.
      Invalid packets are silently discarded.

   Each response packet definition has similar text.

   We note that [RFC2865] and earlier specifications are entirely silent
   on the subject of matching packets based on (src/dst ip/port).  This
   omission was corrected in [RFC5080], Section 2.2.2, seven years after
   the publication of [RFC2865], and more than ten years after the
   publication of the original RADIUS RFC.  We suggest that if RADIUS
   can be used for over a decade with major parts of the protocol being
   entirely unstated, that extending those unstated parts of the
   protocol is not a fundamental change to RADIUS.

   The client is currently unable to use the Request Authenticator as an
   identifier, because that field is not available when it receives the
   response.

   The solution defined herein is that the response contains an
   attribute, Original-Request-Authenticator.  Clients can then use this
   attribute as an additional identifier, to correlate responses with
   requests.

   The Identifier field is still used, but is no longer the sole key
   used to correlate requests and responses.  Since the Request
   Authenticator field is sixteen octets in size, this process allows a
   nearly unlimited number of requests to be outstanding on any
   connection.  More correctly, it allows up to XXX requests and replies
   to be "live" over one connection.  Even allowing for limitations on

DeKok, Alan                  Standards Track                    [Page 7]
INTERNET-DRAFT         Identifying RADIUS packets.         28 April 2017

   Request Authenticator uniques as described below, this should be more
   than sufficient for all practical purposes.

   The final piece of the solution is negotiation.  Clients must be
   aware that servers support this behavior before sending more than 256
   requests on one connection.  Servers must be aware that they need to
   copy the Request Authenticator field from the request packet to the
   contents of the Original-Request-Authenticator attribute in the
   response packet.  As with other specifications (refs...), we use
   Status-Server for negotiation.

   In summary, the use of Original-Request-Authenticator is specific to
   a client-server connection.

3.  Signaling via Status-Server

   When a client supports this functionality, it sends a Status-Server
   packet to the server, containing an Original-Request-Authenticator
   attribute.  See Section X, below, for the definition of the Original-
   Request-Authenticator attribute.

   The contents of the Original-Request-Authenticator attribute MUST be
   zero.  The Original-Request-Authenticator attribute MUST NOT appear
   in any request packet other than Status-Server.

   A server which supports this functionality SHOULD signal that
   capability to the client by sending a response packet which contains
   an Original-Request-Authenticator attribute.  That attribute MUST
   contain a copy of the Request Authenticator from the original Status-
   Server packet.

   When a client sends an Original-Request-Authenticator attribute in a
   Status-Server and does not receive that attribute in the response,
   the client MUST NOT use the Request Authenticator as an identifier
   field.  The client MUST then behave as a normal RADIUS client.

   If a server does not support this functionality, it MUST NOT place an
   Original-Request-Authenticator attribute in the response packet.  As
   the default behavior of existing RADIUS servers is to not place this
   attribute in the response to a Status-Server, negotiation will
   downgrade automatically to using standard RADIUS.

   As the response to a Status-Server can use one of many RADIUS Codes,
   we use a generic "response" name above.  See following sections for
   how to handle specific types of responses.

   Note that this negotation is per connection.  i.e. per combination of
   (transport, src/dst ip/port).  Section X, below, discusses additional

DeKok, Alan                  Standards Track                    [Page 8]
INTERNET-DRAFT         Identifying RADIUS packets.         28 April 2017

   issues related to client/server connections.  In this section, when
   we refer to a client and server performing negotiation, we mean that
   negotiation to be specific to a particular connection.

   Even if a client and server negotiate the use of Original-Request-
   Authenticator, the client can, with no loss of functionality, simply
   fall back to the previous RADIUS behavior.  For example, if the
   server misbehaves and sends either no Original-Request-Authenticator
   attribute, or an invalid one, the client falls back to allowing only
   256 packets outstanding at one time.  There is no need for the client
   to signal the server that it is behaving this way.

   Similarly, if a client and server negotiate the use of Original-
   Request-Authenticator, the server can, with no loss of functionality,
   simply fall back to the previous RADIUS behavior.  For example, if
   the server decides to not honor previous negotiation of the Original-
   Request-Authenticator attribute, it simply stops sending that
   attribute in response packets.  The client then sees that the
   responses have no Original-Request-Authenticator attribute, and falls
   back to using standard RADIUS.

   There is a time frame during this fall back process during which the
   client and server may disagree on the capability of the other party.
   The main side effect of this disagreement is a transient increase in
   packet loss.  This effect will quickly correct itself.

   That packet loss is minimal, and should not cause problems in
   practice.  The possibility of such packet loss should be used instead
   by implementors as incentive to ensure that they do not create
   invalid Original-Request-Authenticator attributes.  Implementing the
   specification correctly will prevent this packet loss from occuring.

   The negotiation outlined here ensures that RADIUS clients and servers
   supporting this functionality are entirely backwards compatible with
   existing RADIUS clients and servers.

3.1.  Static Configuration

   As an alternative to using Status-Server, clients and servers MAY be
   administratively configured with a flag which indicates that the
   other party supports this functionality.  Such a flag can be used
   where the parties are known to each other.  Such a flag is not
   appropriate for dynamic peer discovery [RFC7585], as there are no
   provisions for encoding the flag in the DNS queries or responses.

   When a client is administratively configured to know that a server
   supports this functionality, it SHOULD NOT do negotiation via Status-
   Server.

DeKok, Alan                  Standards Track                    [Page 9]
INTERNET-DRAFT         Identifying RADIUS packets.         28 April 2017

   If a client is administratively configured to believe that a server
   supports the Original-Request-Authenticator attribute, but the
   response packets do not contain an Original-Request-Authenticator
   attribute, the client MUST update its configuration to mark the
   server as not supporting this functionality.

   This process allows for relatively simple downgrade negotiation in
   the event of misconfiguration on either the client or the server.

4.  Original-Request-Authenticator Attribute

   We define a new attribute, called Original-Request-Authenticator.  It
   is intended to be used in response packets, where it contains an
   exact copy of the Request Authenticator field from the original
   request that elicited the response.

   As per the suggestions of [RFC8044], we describe the attribute using
   a data type defined therein, and without the use of ASCII art.

   Type

      TBD - IANA allocation from the "extended" type space

   Length

      19 - TBD double-check this after IANA allocation

   Data Type

      octets

   Value

      MUST be 16 octets in length.  For Status-Server packets, the
      contents of the Value field MUST be zero.  For response packets,
      the contents of the Value field MUST be a copy of the Request
      Authenticator from the original packet that elicited the response.

   The Original-Request-Authenticator attribute can be used in a Status-
   Server packet.

   The Original-Request-Authenticator attribute can be used in a
   response packet.  For example, it can be used in an Access-Accept,
   Accounting-Response, CoA-ACK, etc.

   The Original-Request-Authenticator attribute MUST NOT be used in any
   request packet.  For example, it cannot be used in an Access-Request,
   Accounting-Request, or CoA-Request packet.

DeKok, Alan                  Standards Track                   [Page 10]
INTERNET-DRAFT         Identifying RADIUS packets.         28 April 2017

   Where permitted, the Original-Request-Authenticator attribute MUST
   exist either zero or one times in a packet.  There MUST NOT be
   multiple occurances of the attribute in a packet.

   The contents of the Original-Request-Authenticator attribute MUST
   match the Request Authenticator field of a request packet that the
   client sent, using the same key of (src/dst ip/port, code, Id).

   Where the format and/or contents of the Original-Request-
   Authenticator attribute does not meet these criteria, it MUST be
   treated as an "invalid attribute" as per [RFC6929], Section 2.8.
   That is, when an invalid Original-Request-Authenticator attribute is
   seen by either a client or server, their behavior is to behave as if
   the attribute did not exist, and therefore the parties should fall
   back to using standard RADIUS.

5.  Transport Considerations

   This section describes transport considerations for this
   specification.

   The considerations for DTLS are largely the same as for UDP.  The
   considerations for TLS are largely the same as for TCP.  We therefore
   do not have different sections herein for the TLS-enabled portion of
   the protocols.

5.1.  UDP

   RADIUS over UDP is defined in [RFC2866].  RADIUS over DTLS is defined
   in [RFC7360].

   When negotiated by both peers, this proposal changes the number of
   requests which can be outstanding over a UDP connection.

   Where clients are sending RADIUS packets over UDP, they SHOULD
   include the Original-Request-Authenticator attribute in all Status-
   Server messages to a server, even if the functionality has been
   previously negotiatied.  While the client can generally assume that a
   continual flow of packets means that the server has not been changed,
   this assumption is not true when the server is unresponsive, and the
   client decides it needs to send Status-Server packets.

   Similarly, the server cannot assume that it is respond to the same
   client on every packet.  However, once Original-Request-Authenticator
   has been negotiasted, the server can safely include that attribute in
   all response packets to that client.  If the client changes to not
   supporting the attribute, the attribute will be ignored by the
   client, and the behavior falls back to standard RADIUS.

DeKok, Alan                  Standards Track                   [Page 11]
INTERNET-DRAFT         Identifying RADIUS packets.         28 April 2017

   Where clients are sending RADIUS packets over DTLS, there is an
   underlying TLS session context.  The client can therefore assume that
   all packets for one TLS session are for the same server, with the
   same capabilities.  The server can make the same assumption.

5.2.  TCP

   RADIUS over TCP is defined in [RFC6614].  RADIUS over TLS is defined
   in [RFC6614].

   When negotiated by both peers, this proposal changes the number of
   requests which can be outstanding over a TCP connection.

   Status-Server packets are also used by the application-layer
   watchdog, described in [RFC6614] Section 2.6.  Where clients have
   previously negotiated Original-Request-Authenticator for a
   connection, they MUST continue to send that attribute in all Status-
   Server packets over that connection.

   There are other consideratiosn with the use of Status-Server.  Due to
   the limitations of the ID field, [RFC6613] Section 2.6.5 suggests:

      Implementations SHOULD reserve ID zero (0) on each TCP connection
      for Status-Server packets.  This value was picked arbitrarily, as
      there is no reason to choose any one value over another for this
      use.

   This restriction can now be relaxed when both client and server have
   negotiated the use of the Original-Request-Authenticator attribute.
   Or, with no loss of generality, implementations can continue to use a
   fixed ID field for Status-Server application watchdog messages.

   We also note that the next paragraph of [RFC6614] Section 2.6.5.
   says:

      Implementors may be tempted to extend RADIUS to permit more than
      256 outstanding packets on one connection.  However, doing so is a
      violation of a fundamental part of the protocol and MUST NOT be
      done.  Making that extension here is outside of the scope of this
      specification.

   This specification extends RADIUS in a standard way, making that
   recommendation redundant.

5.3.  Dynamic Discovery

   The dynamic discovery of RADIUS servers is defined in [RFC7585].

DeKok, Alan                  Standards Track                   [Page 12]
INTERNET-DRAFT         Identifying RADIUS packets.         28 April 2017

   This specification is compatible with [RFC7585], with the exception
   of the statically configured flag described in Section X, above.  As
   the server is dynamically discovered, it is impossible to have a
   static flag describing the server capabilities.

   The other considerations for dynamic discovery are the same as for
   RADIUS over TLS.

5.4.  Connection Issues

   Where clients start a new connection to a server (no matter what the
   transport), they SHOULD negotiate this functionality for the new
   connection, unless the ability has been statically configured.  There
   is no guarantee that the new connection goes to the same server.

   When a client has zero connections to a server, it MUST perform this
   negotiation for the new connection, prior to using this
   functionality, unless the ability has been statically configured.
   There is every reason to believe that server has remained the same
   over extended periods of time.

   If a client has one or more connections open to a server, and wishes
   to open a new one, it may skip the renegotiation.

   Each client and server MUST negotiate and track this capability on a
   per-connection basis.  Implementations MUST be able to send packets
   to the same peer at the same time, using both this method, and the
   traditional RADIUS ID allocation.

6.  System Considerations

   This section describes implementation considerations for clients and
   servers.

6.1.  Client Considerations

   Clients SHOULD have an configuration flag which lets administators
   statically configure this behavior for a server.  Clients MUST
   otherwise negotiate this functionality before using it.

   If this functionality has been negotiated, clients MUST use the
   Request Authenticator as an part of the Key used to uniquely identify
   request packets.  The client MUST use the Original-Request-
   Authenticator attribute from response packets as part of the Key to
   find the original request packet.

   The Original-Request-Authenticator attribute has been (or is likely
   to be) allocated from the "extended" attribute space.  We note that

DeKok, Alan                  Standards Track                   [Page 13]
INTERNET-DRAFT         Identifying RADIUS packets.         28 April 2017

   despite this allocation, clients are not required to implement the
   full [RFC6929] specification.  That is, clients may be able to
   originate and receive Original-Request-Authenticator attributes,
   while still being unable to originate or receive any other attribute
   in the "extended" attribute space.

6.2.  Server Considerations

   Servers SHOULD have an configuration flag which lets administators
   statically configure this behavior for a client.  ServersMUST
   otherwise negotiate this functionality before using it.

   If this functionality has been negotiated, clients MUST use the
   Request Authenticator as an part of the key used to uniquely identify
   request packets.

6.3.  Proxy Considerations

   There are additional considerations specific to proxies.  [RFC6929]
   Section 5.2 says in part;

      attributes, even attributes that they do not understand or that
      are not in a local dictionary.  When forwarded, these attributes
      SHOULD be sent verbatim, with no modifications or changes.  This
      requirement includes "invalid attributes", as there may be some
      other system in the network that understands them.

On it's face, this recommendation applies to the Original-Request-
Authenticator attribute.  The caveast is that Section X, above, requires
that servers do not send the Original-Request-Authenticator to clients
unless the clients have first negotiated the use of that attribute.
This requirment should ensure that proxies which are unaware of the
Original-Request-Authenticator attribute will never receive it.

However, if a server has been administratively configured to send
Original-Request-Authenticator to a client, that configuration may be in
error.  In which case a proxy or originating client may erroneously
receive that attribute.  If the proxy or server is unaware of Original-
Request-Authenticator, then no harm is done.

It is possible foraA proxy or client to be aware of Original-Request-
Authenticator, and not negotiate it with a server, but that server (due
to isses outlined above) still forwards the attribute to the proxy or
client.  In that case, the requirements of Section X, above, are that
the client treat the received Original-Request-Authenticator attribure
as an "invalid attribute", and ignore it.

The net effect of these requiremnts and cross-checks is that there are

DeKok, Alan                  Standards Track                   [Page 14]
INTERNET-DRAFT         Identifying RADIUS packets.         28 April 2017

no interoperability issues between existing RADIUS implementations, and
implementations of this specification.

7.  IANA Considerations

   This specification allocates one attribute in the RADIUS Attribute
   Type registry, as follows.

   Name
      Original-Request-Authenticator

   Type
      TBD - allocate from the "extended" space

   Data Type
      octets

8.  Security Considerations

   This proposal does not change the underlying RADIUS security model,
   which is poor.

   The contents of the Original-Request-Authenticator attribute are the
   Request Authenticator, which is already public information for UDP or
   TCP transports.

   The use of Original-Request-Authenticator is defined in such a way
   that all systems fall back gracefully to using standard RADIUS.  As
   such, there are no interoperability issues between this specification
   and existing RADIUS implementations.

   There are few, if any, security considerations related to
   implementations.  Clients already must track the Request
   Authenticator, so matching it in a response packet is minimal extra
   work.  Servers must also track and cache duplicate packets, as per
   [RFC5080] Section 2.2.2, so using the Request Authenticator as an
   additional identifier is minimal extra work.

   The use (or not) of Original-Request-Authenticator has no other
   security considerations, as it is used solely as an identifier to
   match requests and responses.  It has no other meaning or use.

9.  Normative References

DeKok, Alan                  Standards Track                   [Page 15]
INTERNET-DRAFT         Identifying RADIUS packets.         28 April 2017

9.1.

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

[RFC5080]
     Nelson, D., DeKok, A, "Common Remote Authentication Dial In User
     Service (RADIUS) Implementation Issues and Suggested Fixes", RFC
     5080, December 2007.

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

[RFC8044]
     DeKok, A., "Data Types in RADIUS", RFC 8044, January 2017.
     Informative references

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

[RFC5997]
     DeKok, A., "Use of Status-Server Packets in the Remote
     Authentication Dial In User Service (RADIUS) Protocol", RFC 5997,
     August 2017.

[RFC6613]
     DeKok, A., "RADIUS over TCP", RFC 6613, May 2012.

[RFC6614]
     Winter, S., et al, "Transport Layer Security (TLS) Encryption for
     RADIUS", RFC 6614, May 2012.

[RFC7360]
     DeKok, A., "Datagram Transport Layer Security (DTLS) as a Transport
     Layer for RADIUS", RFC 7360, September 2014.

[RFC7585]
     Winter, S., and McCauley, M., "Dynamic Peer Discovery for
     RADIUS/TLS and RADIUS/DTLS Based on the Network Access Identifier
     (NAI)", RFC 7585, October 2015

DeKok, Alan                  Standards Track                   [Page 16]
INTERNET-DRAFT         Identifying RADIUS packets.         28 April 2017

[PATCH]
     Naiming Shen, "Re: [radext] I-D Action: draft-chen-radext-
     identifier-attr-01.txt",
     https://mailarchive.ietf.org/arch/msg/radext/BkXgD68MASxqD4vjXV1M2CaRWAY,
     April 2017.

Acknowledgments

   Parts of the text in Section 3 defining the Request and Response
   Authenticators were taken with minor edits from [RFC2865] Section 3.

   The author would like to thank Mike McCauley of Open Systems
   Consultants for making a Radiator server available for
   interoperability testing.

   Ignacio Goyret provided valuable feedback on the history and security
   of the Status-Server packet.

Author's Address

   Alan DeKok
   The FreeRADIUS Server Project
   http://freeradius.org

   Email: aland@freeradius.org

DeKok, Alan                  Standards Track                   [Page 17]