RADIUS ALPN and removing MD5

3.1. ALPN Name for RADIUS/1.1

The ALPN name defined for RADIUS/1.1 is as follows:¶

• "radius/1.1"¶

  • The protocol defined by this specification.¶

Where ALPN is not configured or is not received in a TLS connection, systems supporting ALPN MUST NOT use RADIUS/1.1.¶

Where ALPN is configured, the client signals support by sending ALPN strings signaling which protocols it supports.. The server can accept one of these proposals and reply with a matching ALPN string, or reject this proposal, and not reply with any ALPN string. A full walk-through of the protocol negotiation is given below.¶

Implementations MUST signal ALPN "radius/1.1" in order for it to be used in a connection. Implementations MUST NOT have an administrative flag which causes a connection to use "radius/1.1", but which does not signal that protocol via ALPN.¶

The next step in defining RADIUS/1.1 is to review how ALPN works.¶

3.2. Operation of ALPN

In order to provide a high-level description of ALPN for readers who are not familiar with the details of [RFC7301], we provide a brief overview here.¶

Once a system has been configured to support ALPN, it is negotiated on a per-connection basis as per [RFC7301]. The negotiation proceeds as follows:¶

1) The client sends an ALPN extension in the ClientHello. This extension lists one or more application protocols by name. These names are the protocols which the client is claiming to support.¶

2) The server receives the extension, and validates the application protocol name(s) against the list it has configured.¶

• If the server finds no acceptable common protocols (ALPN or otherwise), it closes the connection.¶

3) Otherwise, the server returns a ServerHello with either no ALPN extension, or an ALPN extension containing only one named application protocol, which needs to be one of the names proposed by the client.¶

• If the client did not signal ALPN, or the server does not accept the ALPN proposal, the server does not reply with any ALPN name.¶

4) The client receives the ServerHello, validates the received application protocol (if any) against the name(s) it sent, and records which application protocol was chosen.¶

• This check is necessary in order for the client to both know which protocol the server has selected, and to validate that the protocol sent by the server is one which is acceptable to the client.¶

The next step in defining RADIUS/1.1 is to define how ALPN is configured on the client and server, and to give more detailed requirements on its configuration and operation.¶

3.3. Configuration of ALPN for RADIUS/1.1

Clients or servers supporting this specification can do so by extending their TLS configuration through the addition of a new configuration flag, called "Version" here. The exact name given below does not need to be used, but it is RECOMMENDED that administrative interfaces or programming interfaces use a similar name in order to provide consistent terminology. This flag controls how the implementation signals use of this protocol via ALPN.¶

When set, this flag contains the list of permitted ALPN versions in humanly readable form. The implementation may allow multiple values in one variable, or allow multiple variables, or instead use two configuration for "minimum" and "maximum" allowed versions. We assume here that there is one variable, which can contain either no value, or else a list of one or more versions which the current implementation supports. In this specification, the possible values are:¶

• unset,¶
• "1.0" - require historic RADIUS/TLS¶
• "1.0. 1.1" - allow either historic RADIUS/TLS or RADIUS/1.1.¶
• "1.1" - require RADIUS/1.1.¶

This configuration is also extensible to future ALPN names if that extension becomes necessary. New versions can simply be added to the list. Implementations can then negotiate the highest version which is supported by both client and server.¶

Implementations SHOULD support both historic RADIUS/TLS and RADIUS/1.1. Such implementations MUST set the default value for this configuratiun flag to "1.0, 1.1". This setting ensures that both versions of RADIUS can be negotiated.¶

Implementations MAY support only RADIUS/1.1. In which case the default value for this configuration flag MUST be "1.1". This behavior is NOT RECOMMENDED, as it is incompatible with historic RADIUS/TLS. This behavior can only be a reasonable default when all (or nearly all) RADIUS clients have been updated to support RADIUS/1.1.¶

A more detailed definition of the variable and the meaning of the values is given below.¶

Configuration Flag Name¶

• Version¶

Values¶

• When the flag is unset, ALPN is not used.¶

  Any connection MUST use historic RADIUS/TLS.¶

  This flag is included here only for logical completeness. Implementations of this specification SHOULD be configured to always send one or more ALPN strings. This data signals that the implementation is capable performing ALPN negotiation, even if it is not currently configured to use RADIUS/1.1¶

  • Client Behavior¶

    • The client MUST NOT send any protocol name via ALPN.¶

    Server Behavior¶

    • The server MUST NOT signal any protocol name via ALPN.¶

      If the server receives an ALPN name from the client, it MUST NOT close the connection. Instead, it simply does not reply with ALPN, and finishes the TLS connection setup as defined for historic RADIUS/TLS.¶

      Note that if a client sends "radius/1.1", the client will see that the server failed to acknowledge this request, and will close the connection. For any other client configuration, the connection will use historic RADIUS/TLS.¶

• Other values ("1.0", "1.0, 1.1", "1.1", etc.)¶

  • Client Behavior¶

    • The client MUST send the ALPN string(s) associated with the configured version. e.g. For "1.0", send "radius/1.0".¶

      The client will receive either no ALPN response from the server, or an ALPN response of one version string with MUST match one of the strings it sent, or else a TLS alert of "no_application_protocol" (120).¶

      If the connection remains open, the client MUST treat the connection as using the matching ALPN version.¶

    Server Behavior¶

    • If the server receives no ALPN name from the client, it MUST use historic RADIUS/TLS.¶

      If the server receives one or more ALPN names from the client, it MUST reply with the highest mutually supported version and then use the latest supported version for this connection.¶

      If the server receives one or more ALPN names from the client, but none of the names match the versions supported by (or configured on) the server, it MUST reply with a TLS alert of "no_application_protocol" (120), and then MUST close the TLS connection.¶

      These requirements for negotiation are not specific to RADIUS/1.1, and therefore can be used unchanged if any new version of RADIUS is defined.¶

By requiring the default configuration to allow historic RADIUS/TLS, implementations will be able to negotiate both historic RADIUS/TLS connections, and also RADIUS/1.1 connections. Any other recommended default setting would prevent either the negotiation of historic RADIUS/TLS, or prevent the negotiation of RADIUS/1.1.¶

Once administrators verify that both ends of a connection support RADIUS/1.1, and that it has been negotiated successfully, the configurations SHOULD be updated to require RADIUS/1.1. The connections should be monitored after this change to ensure that the systems continue to remain connected. If there are connection issues, then the configuration should be reverted to using allow both "radius/1.0" and "radius/1.1" ALPN strings, until such time as the connection problems have been resolved.¶

We reiterate that systems implementing this specification, but which are configured with setting that forbid RADIUS/1.1, will behave largely the same as systems which do not implement this specification. The only difference is that clients may send the ALPN name "radius/1.0".¶

Systems implementing RADIUS/1.1 SHOULD NOT be configured by default to forbid that protocol. That setting exists mainly for completeness, and to give administrators the flexibility to control their own deployments.¶

While [RFC7301] does not discuss the possibility of the server sending a TLS alert of "no_application_protocol" (120) when the client does not use ALPN, we believe that this behavior is useful. As such, servers MAY send a a TLS alert of "no_application_protocol" (120) when the client does not use ALPN.¶

However, some TLS implementations may not permit an application to send a TLS alert of its choice, at a time of its choice. This limitation means that it is not always possible for an application to send the TLS alert as discussed in the previous section. The impact is that an implementation may attempt to connect, and then see that the connection fails, but not be able to determine why that failure has occurred. Implementers and administrators should be aware that unexplained connection failures may be due to ALPN negotiation issues.¶

The server MAY send this alert during the ClientHello, if it requires ALPN but does not receive it. That is, there may not always be a need to wait for the TLS connection to be fully established before realizing that no common ALPN protocol can be negotiated.¶

Where the client does perform signaling via ALPN and the server determines that there is no compatible application protocol name, then as per [RFC7301], Section 3.2, it MUST send a TLS alert of "no_application_protocol" (120).¶

Whether or not the server sent a TLS alert for no compatible ALPN, it MUST close the connection. The above requirements on ALPN apply to both new sessions, and to resumed sessions.¶

In contrast, there is no need for the client to signal that there are no compatible application protocol names. The client sends zero or more protocol names, and the server responds as above. From the point of view of the client, the list it sent results in either a connection failure, or a connection success.¶

It is RECOMMENDED that the server logs a descriptive error in this situation, so that an administrator can determine why a particular connection failed. The log message SHOULD include information about the other end of the connection, such as IP address, certificate information, etc. Similarly, when the client receives a TLS alert of "no_application_protocol" it SHOULD log a descriptive error message. Such error messages are critical for helping administrators to diagnose connectivity issues.¶

                             Server
             no ALPN  |   1.0    | 1.0, 1.1 |    1.1
Client    |--------------------------------------------
----------|
No ALPN   |   TLS        TLS        TLS        Close-S
          |
1.0       |   TLS        TLS        TLS        Alert
          |
1.0, 1.1  |   TLS        TLS        1.1        1.1
          |
1.1       |   Close-C    Alert      1.1        1.1

3.4. Miscellaneous Items

Implementations of this specification MUST require TLS version 1.3 or later.¶

The use of the ALPN string "radius/1.0" is technically unnecessary, as it is largely equivalent to not sending any ALPN string. However, that value is useful for RADIUS administrators. A system which sends the ALPN string "radius/1.0" is explicitly signaling that it supports ALPN negotiation, but that it is not currently configured to support RADIUS/1.1. That information can be used by administrators to determine which devices are capable of ALPN.¶

The use of the ALPN string "radius/1.0" also permits server implementations to send a TLS alert of "no_application_protocol" (120) when it cannot find a matching ALPN string. Experiments with TLS library implementations suggest that in some cases it is possible to send that TLS alert when ALPN is not used. However, such a scenario is not discussed on [RFC7301], and is likely not universal. As a result, ALPN as defined in [RFC7301] permits servers to send that TLS alert in situations where it would be otherwise forbidden, or perhaps unsupported.¶

Finally, defining ALPN strings for all known RADIUS versions will make it easier to support additional ALPN strings if that functionality is ever needed.¶

3.5. Session Resumption

[RFC7301], Section 3.1 states that ALPN is negotiated on each connection, even if session resumption is used:¶

• When session resumption or session tickets [RFC5077] are used, the previous contents of this extension are irrelevant, and only the values in the new handshake messages are considered.¶

In order to prevent down-bidding attacks, RADIUS systems which negotiate the "radius/1.1" protocol MUST associate that information with the session ticket, and enforce the use of "radius/1.1" on session resumption. That is, if "radius/1.1" was negotiated for a session, both clients and servers MUST behave as if the RADIUS/1.1 flag was set to "require" for that session.¶

A client which is resuming a "radius/1.1" connection MUST advertise only the capability to do "radius/1.1" for the resumed session. That is, even if the client configuration allows historic RADIUS/TLS for new connections, it MUST signal "radius/1.1" when resuming a session which had previously negotiated "radius/1.1".¶

Similarly, when a server does resumption for a session which had previously negotiated "radius/1.1". If the client attempts to resume the sessions without signaling the use of RADIUS/1.1, the server MUST close the connection. The server MUST send an appropriate TLS error, and also SHOULD log a descriptive message as described above.¶

In contrast, there is no requirement for a client or server to force the use of [RFC6614] RADIUS/TLS on session resumption. Clients are free to signal support for "radius/1.1" on resumed sessions, even if the original session did not negotiate "radius/1.1". Servers are free to accept this request, and to negotiate the use of "radius/1.1" for such sessions.¶

4.1. RADIUS/1.1 Packet Format

When RADIUS/1.1 is used, the RADIUS header is modified from standard RADIUS. While the header has the same size, some fields have different meaning. The Identifier and the Request / Response Authenticator fields are no longer used in RADIUS/1.1. Any operations which depend on those fields MUST NOT be performed. As packet signing and security are handled by the TLS layer, RADIUS-specific cryptographic primitives are no longer in RADIUS/1.1.¶

A summary of the RADIUS/1.1 packet format is shown below. The fields are transmitted from left to right.¶

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Code      |  Reserved-1   |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             Token                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                           Reserved-2                          |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-

Code¶

• The Code field is one octet, and identifies the type of RADIUS packet.¶

  The meaning of the Code field is unchanged from previous RADIUS specifications.¶

Reserved-1¶

• The Reserved-1 field is one octet.¶

  This field was previously used as the "Identifier" in historic RADIUS/TLS. It is now unused, as the Token field replaces it both as the way to identify requests, and to associate responses with requests.¶

  When sending packets, the Reserved-1 field MUST be set to zero. The Reserved-1 field MUST be ignored when receiving a packet.¶

Length¶

• The Length field is two octets.¶

  The meaning of the Length field is unchanged from previous RADIUS specifications.¶

Token¶

• The Token field is four octets, and aids in matching requests and replies, as a replacement for the Identifier field. The RADIUS server can detect a duplicate request if it receives the same Token value for two packets on a particular connection.¶

  All values are possible for the Token field. Implementations MUST treat the Token as an opaque blob when comparing Token values.¶

  Further requirements are given below in Section 4.2.1 for sending packets, and in Section 4.2.2 for receiving packets.¶

Reserved-2¶

• The Reserved-2 field is twelve (12) octets in length.¶

  These octets MUST be set to zero when sending a packet.¶

  These octets MUST be ignored when receiving a packet.¶

  These octets are reserved for future protocol extensions.¶

4.2. The Token Field

This section describes in more detail how the Token field is used.¶

5.1. Obfuscated Attributes

Since the (D)TLS layer provides for connection authentication, integrity checks, and confidentiality, there is no need to hide the contents of an attribute on a hop-by-hop basis. As a result, all attributes defined as being obfuscated via the shared secret no longer have the obfuscation step applied when RADIUS/1.1 is used. Instead, those attributes MUST be encoded using the encoding for the underlying data type, with any encryption / obfuscation step omitted. For example, the User-Password attribute is no longer obfuscated, and is instead sent as data type "text".¶

There are risks from sending passwords over the network, even when they are protected by TLS. One such risk comes from the common practice of multi-hop RADIUS routing. As all security in RADIUS is on a hop-by-hop basis, every proxy which receives a RADIUS packet can see (and modify) all of the information in the packet. Sites wishing to avoid proxies SHOULD use dynamic peer discovery [RFC7585], which permits clients to make connections directly to authoritative servers for a realm.¶

There are others ways to mitigate these risks. The simplest is to follow the requirements of [RFC6614], Section 2.4 item (3) and [RFC7360], Section 10.4, which mandates that RADIUS over TLS implementations validate the peer before sending any RADIUS traffic.¶

Another way to mitigate these risks is for the system being authenticated to use an authentication protocol which never sends passwords (e.g. EAP-pwd [RFC5931]), or which sends passwords protected by a TLS tunnel (e.g. EAP-TTLS [RFC5281]). The processes to choose and configuring an authentication protocol are strongly site-dependent, so further discussion of these issues are outside of the scope of this document. The goal here is to ensure that the reader has enough information to make an informed decision.¶

We note that as the RADIUS shared secret is no longer used in this specification, it is no longer possible or necessary for any attribute to be obfuscated on a hop-by-hop basis using the previous methods defined for RADIUS.¶

5.2. Message-Authenticator

The Message-Authenticator attribute ([RFC3579], Section 3.2) MUST NOT be sent over a RADIUS/1.1 connection. That attribute is not used or needed in RADIUS/1.1.¶

If the Message-Authenticator attribute is received over a RADIUS/1.1 connection, the attribute MUST be silently discarded, or treated as an "invalid attribute", as defined in [RFC6929], Section 2.8. That is, the Message-Authenticator attribute is no longer used to sign packets for the RADIUS/1.1 transport. Its existence (or not) in this transport is meaningless.¶

A system which receives a Message-Authenticator attribute in a packet MUST treat it as an "invalid attribute" as defined in [RFC6929], Section 2.8. That is, the packet can still be processed, even if the Message-Authenticator attribute is ignored.¶

For proxies, the Message-Authenticator attribute has always been defined as being created and consumed on a "hop by hop" basis. That is, a proxy which received a Message-Authenticator attribute from a client would never forward that attribute as-is to another server. Instead, the proxy would either suppress, or re-create, the Message-Authenticator attribute in the outgoing request. This existing behavior is leveraged in RADIUS/1.1 to suppress the use of Message-Authenticator over a RADIUS/1.1 connection.¶

A proxy may receive an Access-Request packet over a RADIUS/1.1 connection, and then forward that packet over a RADIUS/UDP or a RADIUS/TCP connection. In that situation, the proxy SHOULD add a Message-Authenticator attribute to every Access-Request packet which is sent over an insecure transport protocol.¶

The original text in [RFC3579], Section 3.3, "Note 1" paragraph required that the Message-Authenticator attribute be present for certain Access-Request packets. It also required the use of Message-Authenticator when the Access-Request packet contained an EAP-Message attribute. Experience has shown that some RADIUS clients never use the Message-Authenticator, even for the situations where its use is suggested.¶

When the Message-Authenticator attribute is missing from Access-Request packets, it is often possible to trivially forge or replay those packets. As such, this document RECOMMENDS that RADIUS clients always include Message-Authenticator in Access-Request packets when using UDP or TCP transport. As the scope of this document is limited to defining RADIUS/1.1, we cannot mandate that behavior here. Instead, we can note that there are no known negatives to this behavior, and there are definite positives, such as increased security.¶

5.3. Message-Authentication-Code

Similarly, the Message-Authentication-Code attribute defined in [RFC6218], Section 3.3 MUST NOT be sent over a RADIUS/1.1 connection. If it is received in a packet, it MUST be treated as "invalid attribute" as defined in [RFC6929], Section 2.8.¶

As the Message-Authentication-Code attribute is no longer used in RADIUS/1.1, the related MAC-Randomizer attribute [RFC6218], Section 3.2 MUST NOT be sent over a RADIUS/1.1 connection. If it is received in a packet, it MUST be treated as "invalid attribute" as defined in [RFC6929], Section 2.8.¶

5.4. CHAP, MS-CHAP, etc.

While some attributes such as CHAP-Password, etc. depend on insecure cryptographic primitives such as MD5, these attributes are treated as opaque blobs when sent between a RADIUS client and server. The contents of the attributes are not obfuscated, and they do not depend on the RADIUS shared secret. As a result, these attributes are unchanged in RADIUS/1.1.¶

A server implementing this specification can proxy CHAP, MS-CHAP, etc. without any issue. A home server implementing this specification can authenticate CHAP, MS-CHAP, etc. without any issue.¶

5.5. Original-Packet-Code

[RFC7930], Section 4 defines an Original-Packet-Code attribute. This attribute is needed because otherwise it is impossible to correlate the Protocol-Error response packet with a particular request packet. The definition in [RFC7930], Section 4 describes the reasoning behind this need:¶

• The Original-Packet-Code contains the code from the request that generated the protocol error so that clients can disambiguate requests with different codes and the same ID.¶

This attribute is no longer needed in RADIUS/1.1. The Identifier field is unused, so it impossible for two requests to have the "same" ID. Instead, the Token field permits clients and servers to correlate requests and responses, independent of the Code value being used.¶

Therefore, the Original-Packet-Code attribute ([RFC7930], Section 4) MUST NOT be sent over a RADIUS/1.1 connection. If it is received in a packet, it MUST be treated as "invalid attribute" as defined in [RFC6929], Section 2.8.¶

6.1. Protocol-Error

There are a number of situations where a RADIUS server is unable to respond to a request. One situation is where the server depends on a database, and the database is down. While arguably the server should close all incoming connections when it is unable to do anything, this action is not always effective. A client may aggressively try to open new connections, or send packets to an unconnected UDP destination where the server is not listening. Another situation where the server is unable to respond is when the server is proxying packets, and the outbound connections are either full or failed.¶

In all RADIUS spercifications prior to this one, there is no way for the server to send a client the positive signal that it received a request, but is unable to send a response. Instead, the server usually just discards the request, which to the client is indistinguishable from the situation where the server is down. This failure case is made worse by the fact that perhaps some proxied packets succeed while others fail. The client can only conclude then that the server is randomly dropping packets, and is unreliable.¶

It would be very useful for servers to signal to clients that they have received a request, but are unable to process it. This specification uses the Protocol-Error packet [RFC7930], Section 4 as that signal. The use of Protocol-Error allows for both hop-by-hop signaling in the case of proxy forwarding errors, and also for end-to-end signaling of server to client. Such signaling should greatly improve the robustness of the RADIUS protocol.¶

When a RADIUS/1.1 server determines that it is unable to process an Access-Request or Accounting-Request packet, it MUST respond with a Protocol-Error packet containing an Error-Cause attribute. A proxy which cannot forward the packet MUST respond with either 502 (Request Not Routable (Proxy)), or 505 (Other Proxy Processing Error). This requirement is to help distinguish failures in the proxy chain from failures at the home server,¶

For a home server, if none of the Error-Cause values match the reason for the failure, then the value 506 (Resources Unavailable) MUST be used.¶

When a RADIUS proxy receives a Protocol-Error reply, it MUST examine the value of the Error-Cause attribute. If there is no Error-Cause attribute, or its value is something other than 502 (Request Not Routable (Proxy)), 505 (Other Proxy Processing Error), or 506 (Resources Unavailable), the proxy MUST return the Protocol-Error response packet to the client, and include the Error-Cause attribute from the response it received. This process allows for full "end to end" signaling of servers to clients.¶

In all situations other then outlined in the preceding paragraph, a client which receives a Protocol-Error reply MUST re-process the original outgoing packet through the client forwarding algorithm. This requirement includes both clients which originate RADIUS traffic, and proxies which see an Error-Cause attribute of 502 (Request Not Routable (Proxy)), or 505 (Other Proxy Processing Error).¶

The expected result of this processing is that the client forwards the packet to a different server. Clients MUST NOT forward the packet over the same connection, and SHOULD NOT forward it to over a different connection to the same server.¶

This process may continue over multiple connections and multiple servers, until the client either times out the request, or fails to find a forwarding destination for the packet. A proxy which is unable to forward a packet MUST reply with a Protocol-Error packet containing Error-Cause, as defined above. A client which originates packets MUST treat such a request as if it had received no response.¶

This behavior is intended to improve the stability of the RADIUS protocol by addressing issues first raised in [RFC3539], Section 2.8.¶

6.2. Status-Server

[RFC6613], Section 2.6.5, and by extension [RFC7360], suggest that the Identifier value zero (0) be reserved for use with Status-Server as an application-layer watchdog. This practice MUST NOT be used for RADIUS/1.1, as the Identifier field is not used in this transport profile.¶

The rationale for reserving one value of the Identifier field was the limited number of Identifiers available (256), and the overlap in Identifiers between Access-Request packets and Status-Server packets. If all 256 Identifier values had been used to send Access-Request packets, then there would be no Identifier value available for sending a Status-Server packet.¶

In contrast, the Token field allows for 2^32 outstanding packets on one RADIUS/1.1 connection. If there is a need to send a Status-Server packet, it is nearly always possible to allocate a new value for the Token field. If instead there are 2^32 outstanding packets for one connection, then it is likely that something has gone catastrophically wrong. In that case, the safest way forward is likely to just close the connection.¶

6.3. Proxies

A RADIUS proxy normally decodes and then re-encodes all attributes, included obfuscated ones. A RADIUS proxy will not generally rewrite the content of the attributes it proxies (unless site-local policy requires such a rewrite). While some attributes may be modified due to administrative or policy rules on the proxy, the proxy will generally not rewrite the contents of attributes such as User-Password, Tunnel-Password, CHAP-Password, MS-CHAP-Password, MS-MPPE keys, etc. All attributes are therefore transported through a RADIUS/1.1 connection without changing their values or contents.¶

A proxy may negotiate RADIUS/1.1 (or not) with a particular client or clients, and it may negotiate RADIUS/1.1 (or not) with a server or servers it connect to, in any combination. As a result, this specification is fully compatible with all past, present, and future RADIUS attributes.¶

7.1. Crypto-Agility

The crypto-agility requirements of [RFC6421] are addressed in [RFC6614], Appendix C, and in [RFC7360], Section 10.1. This specification makes no changes from, or additions to, those specifications. The use of ALPN, and the removal of MD5 has no impact on security or privacy of the protocol.¶

RADIUS/TLS has been widely deployed in at least eduroam [RFC7593] and [EDUROAM] and in OpenRoaming [OPENROAMING]. RADIUS/DTLS has seen less adoption, but it is known to be supported in many RADIUS clients and servers.¶

It is RECOMMENDED that all implementations of historic RADIUS/TLS be updated to support this specification. Where a system already implements RADIUS over TLS, the additional effort to implement this specification is minimal. Once implementations support it, administrators can gain the benefit of it with little or no configuration changes. This specification is backwards compatible with [RFC6614] and [RFC7360]. It is only potentially subject to down-bidding attacks if implementations do not enforce ALPN negotiation correctly on session resumption.¶

All crypto-agility needed or used by this specification is implemented in TLS. This specification also removes all cryptographic primitives from the application-layer protocol (RADIUS) being transported by TLS. As discussed in the following section, this specification also bans the development of all new cryptographic or crypto-agility methods in the RADIUS protocol.¶

7.2. Error-Cause Attribute

The Error-Cause attribute is defined in [RFC5176]. The "Table of Attributes" section given in [RFC5176], Section 3.6 permits that attribute to appear in CoA-NAK and Disconnect-NAK packets. As no other packet type is listed, the implication is that the Error-Cause attribute cannot appear in any other packet. [RFC7930] also permits Error-Cause to appear in Protocol-Error packets.¶

However, [RFC5080], Section 2.6.1 suggests that Error-Cause may appear in Access-Reject packets. No explanation is given for this change from [RFC5176]. There is not even an acknowledgment that this suggestion is a change from any previous specification. We correct that issue here.¶

This specification updates [RFC5176] to allow the Error-Cause attribute to appear in Access-Reject packets. It is RECOMMENDED that implementations include the Error-Cause attribute in Access-Reject packets where appropriate.¶

That is, the reason for sending the Access-Reject packet (or Protocol-Error packet) may match a defined Error-Cause value. In that case, it is useful for implementations to send an Error-Cause attribute with that value. This behavior can help RADIUS system administrators debug issues in complex proxy chains.¶

For example, a proxy may normally forward Access-Request packets which contain EAP-Message attributes. The proxy can determine if the contents of the EAP-Message are invalid, for example if the first octet has value larger than 4. In that case, there may be no benefit to forwarding the packet, as the home server will reject it. It may then then possible for the proxy (with the knowledge and consent of involved parties) to immediately reply with an Access-Reject containing an Error-Cause attribute with value 202 for "Invalid EAP Packet (Ignored)".¶

Another possibility is that if a proxy is configured to forward packets for a particular realm, but it has determined that there are no available connections to the next hop for that realm. In that case, it may be possible for the proxy (again with the knowledge and consent of involved parties) to reply with an Access-Reject containing an Error-Cause attribute with value 502 for "Request Not Routable (Proxy)"¶

These examples are given only for illustrative and informational purposes. While it is useful to return an informative value for the Error-Cause attribute, proxies can only modify the traffic they forward with the explicit knowledge and consent of all involved parties.¶

7.3. Future Standards

Future work may define new attributes, packet types, etc. It is important to be able to do such work without requiring that every new standard mention RADIUS/1.1 explicitly. Instead, this document defines a mapping from RADIUS to RADIUS/1.1 which covers all RADIUS practices and cryptographic primitives in current use. As a result, any new standard which uses the existing RADIUS practices can simply inherit that mapping, and they do not need to mention RADIUS/1.1 explicitly.¶

We reiterate that this specification defines a new transport profile for RADIUS. It does not define a completely new protocol. Any future specification which defines a new attribute MUST define it for RADIUS/UDP first, after which those definitions can be applied to this transport profile.¶

New specifications MAY define new attributes which use the obfuscation methods for User-Password as defined in [RFC2865], Section 5.2, or for Tunnel-Password as defined in [RFC2868], Section 3.5. There is no need for those specifications to describe how those new attributes are transported in RADIUS/1.1. Since RADIUS/1.1 does not use MD5, any obfuscated attributes will by definition be transported as their underlying data type, "text" ([RFC8044], Section 3.4) or "string" ([RFC8044], Section 3.5).¶

New RADIUS specifications MUST NOT define attributes which can only be transported via RADIUS over TLS. The RADIUS protocol has no way to signal the security requirements of individual attributes. Any existing implementation will handle these new attributes as "invalid attributes" ([RFC6929], Section 2.8), and could forward them over an insecure link. As RADIUS security and signaling is hop-by-hop, there is no way for a RADIUS client or server to even know if such forwarding is taking place. For these reasons and more, it is therefore inappropriate to define new attributes which are only secure if they use a secure transport layer.¶

The result is that specifications do not need to mention this transport profile, or make any special provisions for dealing with it. This specification defines how RADIUS packet encoding, decoding, signing, and verification are performed when using RADIUS/1.1. So long as any future specification uses the existing encoding, etc. schemes defined for RADIUS, no additional text in future documents is necessary in order to be compatible with RADIUS/1.1.¶

We note that it is theoretically possible for future standards to define new cryptographic primitives for use with RADIUS/UDP. In that case, those documents would likely have to describe how to transport that data in RADIUS/1.1. We believe that such standards are unlikely to be published, as other efforts in the RADEXT working group are forbidding such updates to RADIUS.¶