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

quot;used" or "free" status for
   individual IDs.  Instead, the client can re-use IDs at will, and can
   rely on the uniqueness of the Request Authenticator to disambiguate
   packets.

   As there is no need to track ID status, the client may simply
   allocate IDs by incrementing a local counter.

   With this specification, the client still needs to track all outgoing
   requests, but that work was already required in traditional RADIUS.

   Client implementors may be tempted to require that the Original-
   Request-Authenticator be the first attribute after the RADIUS header.
   We state instead that clients implementing this specification MUST
   accept the Original-Request-Authenticator attribute, no matter where
   it is in the response.  We remind implementors that this
   specification adds a new attribute, it does not change the RADIUS
   header.

   Finally, we note that clients MUST NOT set the ID field to a fixed
   value for all packets.  While it is beneficial to use the Request
   Authenticator as an identifier, removing the utility of an existing
   identifier is unwarranted.

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

8.2.  Server Considerations

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

   If this functionality has been negotiated, servers MUST use the
   Request Authenticator as an part of the key used to uniquely identify
   request packets.  Servers 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
   despite this allocation, servers are not required to implement the
   full [RFC6929] specification.  That is, servers 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.

8.3.  Proxy Considerations

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

       Proxy servers SHOULD forward 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

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

   (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 no interoperability issues between existing RADIUS
   implementations, and implementations of this specification.

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

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

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

10.1.  Access-Request Forging

   The Request Authenticator in Access-Request packets is defined to be
   a 16 octet random number [RFC 2865] Section 3.  As such, these
   packets can be trivially forged.

   The Message-Authenticator attribute was defined in [RFC2869] Section
   5.14 in order to address this issue.  Further, [RFC5080] Section
   2.2.2 suggests that client implementations SHOULD include a Message-
   Authenticator attribute in every Access-Request to further help
   mitigate this issue.

   The Status-Server packets also have a Request Authenticator which is
   a 16-octet random number [RFC5997] Section 3.  However, [RFC5997]
   Section Section 2 says that a Message-Authenticator attribute MUST be
   included in every Status-Server packet, which provides per-packet
   authentication and integrity protection.

   We extend that suggestion for this specification.  Where the
   transport does not provide for authentication or integrity protection
   (e.g. RADIUS over UDP or RADIUS over TCP), each Access-Request packet
   using this specification MUST include a Message-Authenticator
   attribute.  This inclusion ensures that packets are accepted only
   from clients which know the RADIUS shared secret.

   This protection is, of course, insufficient.  Malicious or
   misbehaving clients can create Access-Request packets which re-use
   Request Authenticators.  These clients can also create Request
   Authenticators which exploit implementation issues in servers, such
   as turning a simply binary lookup into a linked list lookup.

   As a result, server implementations MUST NOT assume that the Request
   Authenticator is random.  Server implementations MUST be able to
   detect re-use of Request Authenticators.

   When a server detects that a Request Authenticator is re-used, it
   MUST replace the older request with the newer request.  It MUST NOT
   respond to the older request.  It SHOULD issue a warning message to
   the administrator that the client is malicious or misbehaving.

   Server implementations SHOULD use data structures such as Red-Black
   trees, which are immune to maliciously crafted Request
   Authenticators.

10.2.  MD5 Collisions

   For other packet types (Accounting-Request, etc.), the Request
   Authenticator is the MD5 signature of the packet and the shared

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

   secret.  Since this data is used directly as an identifier, we need
   to examine the security issues related to this practice.

   We must note that MD5 has been broken, in that there is a published
   set of work which describes how to create two sets of input data
   which have the same MD5 hash.  These attacks have been extended to
   create sets of data of arbitrary length, which differ only in 128
   bytes, and have the same MD5 hash.

   This attack is possible in RADIUS, as the protocol has the capability
   to transport opaque binary data in (for example) Vendor-Specific
   attributes.  There is no need for the client or server to understand
   the data, it simply has to exist in the packet for the attack to
   succeed.

   Another attack allows two sets of data to have the same MD5 hash, by
   appending thousands of bytes of carefully crafted data to the end of
   the file.  This attack is also possible in RADIUS, as the maximum
   packet size for UDP is 4096 octets, and [RFC7930] permits packets up
   to 65535 octets in length.

   However, as the packets are authenticated with the shared secret,
   these attacks can only be performed by clients who are in possession
   of the shared secret.  That is, only trusted clients can create MD5
   collisions.

   We note that this specification requires server implementations to
   detect duplicates, and to process only one of the packets.  This
   requirement could be exploited by a client to force a server to do
   large amounts of work, partially processing a packet which is then
   made obselete by a subsequent packet.  This attack can be done in
   RADIUS today, so this specification adds no new security issues to
   the protocol.

   In fact, this specification describes the problem of "conflicting
   packets" for the first time, and defines how they should be processed
   by servers.  This addition to the RADIUS protocol in fact increases
   it's security, by specifying how this corner case should be handled.
   The fact that RADIUS has been widely implemented for almost 25 years
   without this issue being described shows that the protocol and
   implementations are robust.

   We do not offer a technical solution to the problem of trusted
   parties misbehaving.  Instead, the problem should be noted by the
   server which is being attacked, and administrative (i.e. human)
   intervention should take place.

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

11.  Normative References

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

[RFC2869]
     Rigney, C. et. al., "RADIUS Extensions", RFC 2869, 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.

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

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

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

[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

[RFC7930]
     Hartman, S., "Larger Packets for RADIUS over TCP", RFC 7930, August
     2016.

[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

Author's Address

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

   Email: aland@freeradius.org

DeKok, Alan                  Standards Track                   [Page 28]