rfc9765v1.txt   rfc9765.txt 
skipping to change at line 81 skipping to change at line 81
4.2.1. Sending Packets 4.2.1. Sending Packets
4.2.2. Receiving Packets 4.2.2. Receiving Packets
5. Attribute Handling 5. Attribute Handling
5.1. Obfuscated Attributes 5.1. Obfuscated Attributes
5.1.1. User-Password 5.1.1. User-Password
5.1.2. CHAP-Challenge 5.1.2. CHAP-Challenge
5.1.3. Tunnel-Password 5.1.3. Tunnel-Password
5.1.4. Vendor-Specific Attributes 5.1.4. Vendor-Specific Attributes
5.2. Message-Authenticator 5.2. Message-Authenticator
5.3. Message-Authentication-Code 5.3. Message-Authentication-Code
5.4. CHAP, MS-CHAP, etc. 5.4. CHAP, MS-CHAP, and Similar Attributes
5.5. Original-Packet-Code 5.5. Original-Packet-Code
6. Other Considerations When Using ALPN 6. Other Considerations When Using ALPN
6.1. Protocol-Error 6.1. Protocol-Error
6.2. Status-Server 6.2. Status-Server
6.3. Proxies 6.3. Proxies
7. Other RADIUS Considerations 7. Other RADIUS Considerations
7.1. Crypto-Agility 7.1. Crypto-Agility
7.2. Error-Cause Attribute 7.2. Error-Cause Attribute
7.3. Future Standards 7.3. Future Standards
8. Privacy Considerations 8. Privacy Considerations
skipping to change at line 119 skipping to change at line 119
was that this continued use of MD5 was acceptable. TLS was seen as a was that this continued use of MD5 was acceptable. TLS was seen as a
simple "wrapper" around RADIUS, while using a fixed shared secret. simple "wrapper" around RADIUS, while using a fixed shared secret.
The intention at the time was to allow the use of (D)TLS while making The intention at the time was to allow the use of (D)TLS while making
essentially no changes to the basic RADIUS encoding, decoding, essentially no changes to the basic RADIUS encoding, decoding,
authentication, and packet validation. authentication, and packet validation.
Issues of MD5 security have been known for decades, most notably in Issues of MD5 security have been known for decades, most notably in
[RFC6151] and in Section 3 of [RFC6421], among others. The reliance [RFC6151] and in Section 3 of [RFC6421], among others. The reliance
on MD5 for security makes it impossible to use RADIUS in secure on MD5 for security makes it impossible to use RADIUS in secure
systems that forbid the use of digest algorithms with known systems that forbid the use of digest algorithms with known
vulnerabilities. For example, FIPS-140 forbids systems from relying vulnerabilities. For example, FIPS 140 forbids systems from relying
on insecure cryptographic methods for security. on insecure cryptographic methods for security [FIPS-140-3].
While the use of MD5 in RADIUS/TLS is not known to be insecure, it While the use of MD5 in RADIUS/TLS has not been proven to be
can be difficult for individual organizations to perform insecure, it has not been proven to be secure. This gap means that
cryptographic analyses of the protocols that they use. It is much it is difficult to use RADIUS in organizations that require the use
simpler and more practical to simply verify that their insecure of systems that have proven security. Those organizations tend to
digests such as MD5 are not used anywhere in the system. Then by simply ban the use of insecure digests such as MD5 entirely, even if
definition, the systems are at least not known to be insecure. the use of MD5 has no known security impact. While the resulting
system might still not be secure, it at least does not contain any
known insecurities.
In addition, the use of MD5 in RADIUS/TLS and RADIUS/DLTS adds no In addition, the use of MD5 in RADIUS/TLS and RADIUS/DLTS adds no
security or privacy over that provided by TLS. In hindsight, the security or privacy over that provided by TLS. In hindsight, the
decision of the RADEXT Working Group to retain MD5 for historic decision of the RADEXT Working Group to retain MD5 for historic
RADIUS/TLS was likely wrong. It was an easy decision to make in the RADIUS/TLS was likely wrong. It was an easy decision to make in the
short term, but it has caused ongoing problems that this document short term, but it has caused ongoing problems that this document
addresses. The author of this document played a part in that addresses. The author of this document played a part in that
original decision, which is now being corrected by this document. original decision, which is now being corrected by this document.
This document defines an Application-Layer Protocol Negotiation This document defines an Application-Layer Protocol Negotiation
(ALPN) [RFC7301] extension for RADIUS over (D)TLS that removes the (ALPN) [RFC7301] extension for RADIUS over (D)TLS that removes the
need to use MD5 for (D)TLS, which we call RADIUS/1.1. This need to use MD5 for (D)TLS, which we call RADIUS/1.1. This
specification makes no changes to UDP or TCP transport. The specification makes no changes to UDP or TCP transport. The
RADIUS/1.1 protocol can be best understood as a transport profile for RADIUS/1.1 protocol can be best understood as a transport profile for
RADIUS over TLS, rather than a wholesale revision of the RADIUS RADIUS over TLS, rather than a wholesale revision of the RADIUS
protocol. protocol.
Systems that implement this transport profile can be more easily Systems that implement this transport profile can be more easily
verified to be FIPS-140 compliant. A preliminary implementation has verified to be FIPS 140 compliant. A preliminary implementation has
shown that only minor code changes are required to support RADIUS/1.1 shown that only minor code changes are required to support RADIUS/1.1
on top of an existing RADIUS/TLS server implementation. These on top of an existing RADIUS/TLS server implementation. These
include: include:
* A method to set the list of supported ALPN protocols before the * A method to set the list of supported ALPN protocols before the
TLS handshake starts. TLS handshake starts.
* A method to query if ALPN has chosen a protocol (and if yes, which * A method to query if ALPN has chosen a protocol (and if yes, which
protocol was chosen) after the TLS handshake has completed. protocol was chosen) after the TLS handshake has completed.
skipping to change at line 200 skipping to change at line 202
obfuscation. This obfuscation is no longer necessary, as the data obfuscation. This obfuscation is no longer necessary, as the data
is secured and kept private through the use of TLS. is secured and kept private through the use of TLS.
* The conclusion of the efforts stemming from [RFC6421] is that * The conclusion of the efforts stemming from [RFC6421] is that
crypto-agility in RADIUS is best done via a TLS wrapper, and not crypto-agility in RADIUS is best done via a TLS wrapper, and not
by extending the RADIUS protocol. by extending the RADIUS protocol.
* [RFC5176] is updated to allow the Error-Cause attribute to appear * [RFC5176] is updated to allow the Error-Cause attribute to appear
in Access-Reject packets. in Access-Reject packets.
The following items are left unchanged from traditional TLS-based The following items are left unchanged from historic TLS-based
transports for RADIUS: transports for RADIUS:
* The RADIUS packet header is the same size, and the Code and Length * The RADIUS packet header is the same size, and the Code and Length
fields ([RFC2865], Section 3) have the same meaning as before. fields ([RFC2865], Section 3) have the same meaning as before.
* The default 4K packet size is unchanged, although [RFC7930] can * The default 4096-octet packet size from [RFC2865], Section 3 is
still be leveraged to use larger packets. unchanged, although [RFC7930] can still be leveraged to use larger
packets.
* All attributes that have simple encodings (that is, attributes * All attributes that have simple encodings (that is, attributes
that do not use MD5 obfuscation) have the same encoding and that do not use MD5 obfuscation) have the same encoding and
meaning as before. meaning as before.
* As this extension is a transport profile for one "hop" (client-to- * As this extension is a transport profile for one "hop" (client-to-
server connection), it does not impact any other connection used server connection), it does not impact any other connection used
by a client or server. The only systems that are aware that this by a client or server. The only systems that are aware that this
transport profile is in use are the client and server who have transport profile is in use are the client and server who have
negotiated the use of this extension on a particular shared negotiated the use of this extension on a particular shared
connection. connection.
* This extension uses the same ports (2083/tcp and 2083/udp) that * This extension uses the same ports (2083/tcp and 2083/udp) that
are defined for RADIUS/TLS [RFC6614] and RADIUS/DTLS [RFC7360]. are defined for RADIUS/TLS [RFC6614] and RADIUS/DTLS [RFC7360].
A major benefit of this extension is that a server that implements it A major benefit of this extension is that a server that implements it
can also be more easily verified for FIPS-140 compliance. That is, a can also be more easily verified for FIPS 140 compliance. That is, a
server can remove all uses of MD5, which means that those algorithms server can remove all uses of MD5, which means that those algorithms
are provably not used for security purposes. In that case, however, are provably not used for security purposes. In that case, however,
the server will not support the Challenge Handshake Authentication the server will not support the Challenge Handshake Authentication
Protocol (CHAP) or any authentication method that uses MD5. The Protocol (CHAP) or any authentication method that uses MD5. The
choice of which authentication method to accept is always left to the choice of which authentication method to accept is always left to the
server. This specification does not change any authentication method server. This specification does not change any authentication method
carried in RADIUS, and does not mandate (or forbid) the use of any carried in RADIUS, and does not mandate (or forbid) the use of any
authentication method for any system. authentication method for any system.
As for proxies, there was never a requirement that proxies implement As for proxies, there was never a requirement that proxies implement
CHAP or Microsoft CHAP (MS-CHAP) authentication. So far as a proxy CHAP or Microsoft CHAP (MS-CHAP) authentication. So far as a proxy
is concerned, attributes relating to CHAP and MS-CHAP are simply is concerned, attributes relating to CHAP and MS-CHAP are simply
opaque data that is transported unchanged to the next hop. opaque data that is transported unchanged to the next hop.
Therefore, it is possible for a FIPS-140 compliant proxy to transport Therefore, it is possible for a FIPS 140 compliant proxy to transport
authentication methods that depend on MD5, so long as that data is authentication methods that depend on MD5, so long as that data is
forwarded to a server that supports those methods. forwarded to a server that supports those methods.
We reiterate that the decision to support (or not support) any We reiterate that the decision to support (or not support) any
authentication method is entirely site local, and is not a authentication method is entirely site local, and is not a
requirement of this specification. The contents or meaning of any requirement of this specification. The contents or meaning of any
RADIUS attribute other than the Message-Authenticator (and similar RADIUS attribute other than the Message-Authenticator (and similar
attributes) are not modified. The only change to the Message- attributes) are not modified. The only change to the Message-
Authenticator attribute is that it is no longer used in RADIUS/1.1. Authenticator attribute is that it is no longer used in RADIUS/1.1.
skipping to change at line 464 skipping to change at line 467
RADIUS/TLS. This behavior can only be a reasonable default when all RADIUS/TLS. This behavior can only be a reasonable default when all
(or nearly all) RADIUS clients have been updated to support (or nearly all) RADIUS clients have been updated to support
RADIUS/1.1. RADIUS/1.1.
A more detailed definition of the variable and the meaning of the A more detailed definition of the variable and the meaning of the
values is given below. values is given below.
Configuration Variable Name Configuration Variable Name
Version Version
Values For "Value":
When the variable is unset, ALPN is not used. A. If unset, ALPN is not used.
Any connection MUST use historic RADIUS/TLS. Any connection MUST use historic RADIUS/TLS.
This variable is included here only for logical completeness. This variable is included here only for logical completeness.
Implementations of this specification SHOULD be configured to Implementations of this specification SHOULD be configured to
always send one or more ALPN strings. This data signals that the always send one or more ALPN strings. This data signals that
implementation is capable of performing ALPN negotiation, even if the implementation is capable of performing ALPN negotiation,
it is not currently configured to use RADIUS/1.1. even if it is not currently configured to use RADIUS/1.1.
Client Behavior Client Behavior
The client MUST NOT send any protocol name via ALPN. The client MUST NOT send any protocol name via ALPN.
Server Behavior Server Behavior
The server MUST NOT signal any protocol name via ALPN. The server MUST NOT signal any protocol name via ALPN.
If the server receives an ALPN name from the client, it MUST If the server receives an ALPN name from the client, it
NOT close the connection. Instead, it simply does not reply MUST NOT close the connection. Instead, it simply does not
with ALPN and finishes the TLS connection setup as defined for reply with ALPN and finishes the TLS connection setup as
historic RADIUS/TLS. defined for historic RADIUS/TLS.
Note that if a client sends "radius/1.1", the client will see Note that if a client sends "radius/1.1", the client will
that the server failed to acknowledge this request and will see that the server failed to acknowledge this request and
close the connection. For any other client configuration, the will close the connection. For any other client
connection will use historic RADIUS/TLS. configuration, the connection will use historic RADIUS/TLS.
Other values ("1.0", "1.0, 1.1", "1.1", etc.) B. If set to "1.0", "1.0, 1.1", "1.1", or future values:
Client Behavior
The client MUST send the ALPN string(s) associated with the
configured version. For example, send "radius/1.0" for "1.0".
The client will receive either no ALPN response from the Client Behavior
server, or an ALPN response of one version string with MUST The client MUST send the ALPN string(s) associated with the
match one of the strings it sent, or else a TLS alert of configured version. For example, send "radius/1.0" for
"no_application_protocol" (120). "1.0".
If the connection remains open, the client MUST treat the The client will receive either no ALPN response from the
connection as using the matching ALPN version. server; or it will receive an ALPN response of one version
string that MUST match one of the strings it sent; or else
they will receive a TLS alert of "no_application_protocol"
(120).
Server Behavior If the connection remains open, the client MUST treat the
If the server receives no ALPN name from the client, it MUST connection as using the matching ALPN version.
use historic RADIUS/TLS.
If the server receives one or more ALPN names from the client, Server Behavior
it MUST reply with the highest mutually supported version and If the server receives no ALPN name from the client, it
then use the latest supported version for this connection. MUST use historic RADIUS/TLS.
If the server receives one or more ALPN names from the client, If the server receives one or more ALPN names from the
but none of the names match the versions supported by (or client, it MUST reply with the highest mutually supported
configured on) the server, it MUST reply with a TLS alert of version and then use the latest supported version for this
"no_application_protocol" (120), and then it MUST close the TLS connection.
connection.
These requirements for negotiation are not specific to If the server receives one or more ALPN names from the
RADIUS/1.1; therefore, they can be used unchanged if any new client, but none of the names match the versions supported
version of RADIUS is defined. by (or configured on) the server, it MUST reply with a TLS
alert of "no_application_protocol" (120), and then it MUST
close the TLS connection.
These requirements for negotiation are not specific to
RADIUS/1.1; therefore, they can be used unchanged if any
new version of RADIUS is defined.
By requiring the default configuration to allow historic RADIUS/TLS, By requiring the default configuration to allow historic RADIUS/TLS,
implementations will be able to negotiate both historic RADIUS/TLS implementations will be able to negotiate both historic RADIUS/TLS
connections and also RADIUS/1.1 connections. Any other recommended connections and also RADIUS/1.1 connections. Any other recommended
default setting would prevent either the negotiation of historic default setting would prevent either the negotiation of historic
RADIUS/TLS or prevent the negotiation of RADIUS/1.1. RADIUS/TLS or prevent the negotiation of RADIUS/1.1.
Once administrators verify that both ends of a connection support Once administrators verify that both ends of a connection support
RADIUS/1.1, and that it has been negotiated successfully, the RADIUS/1.1, and that it has been negotiated successfully, the
configurations SHOULD be updated to require RADIUS/1.1. The configurations SHOULD be updated to require RADIUS/1.1. The
connections should be monitored after this change to ensure that the connections should be monitored after this change to ensure that the
systems continue to remain connected. If there are connection systems continue to remain connected. If there are connection
issues, then the configuration should be reverted to using allow both issues, then the configuration should be reverted to allowing both
"radius/1.0" and "radius/1.1" ALPN strings, until such time as the "radius/1.0" and "radius/1.1" ALPN strings, until the administrator
connection problems have been resolved. has resolved the connection problems.
We reiterate that systems implementing this specification, but which We reiterate that systems implementing this specification, but which
are configured with settings that forbid RADIUS/1.1, will behave are configured with settings that forbid RADIUS/1.1, will behave
largely the same as systems that do not implement this specification. largely the same as systems that do not implement this specification.
The only difference is that clients may send the ALPN name The only difference is that clients may send the ALPN name
"radius/1.0". "radius/1.0".
Systems implementing RADIUS/1.1 SHOULD NOT be configured by default Systems implementing RADIUS/1.1 SHOULD NOT be configured by default
to forbid that protocol. That setting exists mainly for to forbid that protocol. That setting exists mainly for
completeness, and to give administrators the flexibility to control completeness, and to give administrators the flexibility to control
skipping to change at line 561 skipping to change at line 568
such, servers MAY send a TLS alert of "no_application_protocol" (120) such, servers MAY send a TLS alert of "no_application_protocol" (120)
when the client does not use ALPN. when the client does not use ALPN.
However, some TLS implementations may not permit an application to However, some TLS implementations may not permit an application to
send a TLS alert of its choice at a time of its choice. This 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 limitation means that it is not always possible for an application to
send the TLS alert as discussed in the previous section. The impact send the TLS alert as discussed in the previous section. The impact
is that an implementation may attempt to connect and then see that is that an implementation may attempt to connect and then see that
the connection fails, but it may not be able to determine why that the connection fails, but it may not be able to determine why that
failure has occurred. Implementers and administrators should be failure has occurred. Implementers and administrators should be
aware that unexplained connection failures may be due to ALPN aware that unexplained connection failures may be due to ALPN issues.
negotiation issues.
The server MAY send this alert during the ClientHello if it requires 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 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 need to wait for the TLS connection to be fully established before
realizing that no common ALPN protocol can be negotiated. realizing that no common ALPN protocol can be negotiated.
Where the client does perform signaling via ALPN, and the server Where the client does perform signaling via ALPN, and the server
determines that there is no compatible application protocol name, determines that there is no compatible application protocol name,
then as per [RFC7301], Section 3.2, it MUST send a TLS alert of then as per [RFC7301], Section 3.2, it MUST send a TLS alert of
"no_application_protocol" (120). "no_application_protocol" (120).
skipping to change at line 637 skipping to change at line 643
The purpose of this packet is not to have the other end of the The purpose of this packet is not to have the other end of the
connection automatically determine what went wrong and fix it. connection automatically determine what went wrong and fix it.
Instead, the packet is intended to be (eventually) seen by an Instead, the packet is intended to be (eventually) seen by an
administrator, who can then take remedial action. administrator, who can then take remedial action.
3.3.2. Tabular Summary 3.3.2. Tabular Summary
The preceding text gives a large number of recommendations. In order The preceding text gives a large number of recommendations. In order
to give a simpler description of the outcomes, a table of possible to give a simpler description of the outcomes, a table of possible
behaviors for client/server values of the Version variable is given behaviors for client/server values of the Version variable is given
below. This table and the names given below are for informational below. The row and column headings are the RADIUS version numbers
and descriptive purposes only. sent in ALPN (or no ALPN). The contents of the table are the
resulting RADIUS version that is negotiated. For clarity, only the
RADIUS version numbers have been given, and not the full ALPN strings
(e.g., "radius/1.0").
This table and the names given below are for informational and
descriptive purposes only.
+==========+======================================+ +==========+======================================+
| Client | Server | | Client | Server |
| +=========+=======+==========+=========+ | +=========+=======+==========+=========+
| | no ALPN | 1.0 | 1.0, 1.1 | 1.1 | | | no ALPN | 1.0 | 1.0, 1.1 | 1.1 |
+==========+=========+=======+==========+=========+ +==========+=========+=======+==========+=========+
| no ALPN | TLS | TLS | TLS | Close-S | | no ALPN | TLS | TLS | TLS | Close-S |
+==========+---------+-------+----------+---------+ +==========+---------+-------+----------+---------+
| 1.0 | TLS | TLS | TLS | Alert | | 1.0 | TLS | TLS | TLS | Alert |
+==========+---------+-------+----------+---------+ +==========+---------+-------+----------+---------+
| 1.0, 1.1 | TLS | TLS | 1.1 | 1.1 | | 1.0, 1.1 | TLS | TLS | 1.1 | 1.1 |
+==========+---------+-------+----------+---------+ +==========+---------+-------+----------+---------+
| 1.1 | Close-C | Alert | 1.1 | 1.1 | | 1.1 | Close-C | Alert | 1.1 | 1.1 |
+==========+---------+-------+----------+---------+ +==========+---------+-------+----------+---------+
Table 2: Possible Outcomes for ALPN Negotiation Table 2: Possible Outcomes for ALPN
The table entries above have the following meaning: The table entries above have the following meaning:
Alert Alert
The client sends ALPN, and the server does not agree to the The client sends ALPN, and the server does not agree to the
client's ALPN proposal. The server replies with a TLS alert of client's ALPN proposal. The server replies with a TLS alert of
"no_application_protocol" (120) and then closes the TLS "no_application_protocol" (120) and then closes the TLS
connection. connection.
As the server replies with a TLS alert, the Protocol-Error packet As the server replies with a TLS alert, the Protocol-Error packet
skipping to change at line 696 skipping to change at line 708
ALPN string or with "radius/1.0". The connection MUST use ALPN string or with "radius/1.0". The connection MUST use
historic RADIUS/TLS. historic RADIUS/TLS.
1.1 1.1
The client sends the ALPN string "radius/1.1". The server The client sends the ALPN string "radius/1.1". The server
acknowledges this negotiation with a reply of "radius/1.1", and acknowledges this negotiation with a reply of "radius/1.1", and
then RADIUS/1.1 is used. then RADIUS/1.1 is used.
Implementations should note that this table may be extended in future Implementations should note that this table may be extended in future
specifications. The above text is informative, and does not mandate specifications. The above text is informative, and does not mandate
that only the above ALPN strings are used. The actual ALPN that only the above ALPN strings are used. The actual ALPN takes
negotiation takes place as defined in the preceding sections of this place as defined in the preceding sections of this document and in
document and in [RFC7301]. [RFC7301].
3.4. Miscellaneous Items 3.4. Miscellaneous Items
Implementations of this specification MUST require TLS version 1.3 or Implementations of this specification MUST require TLS version 1.3 or
later. later.
The use of the ALPN string "radius/1.0" is technically unnecessary, The use of the ALPN string "radius/1.0" is technically unnecessary,
as it is largely equivalent to not sending any ALPN string. However, as it is largely equivalent to not sending any ALPN string. However,
that value is useful for RADIUS administrators. A system that sends that value is useful for RADIUS administrators. A system that sends
the ALPN string "radius/1.0" is explicitly signaling that it supports the ALPN string "radius/1.0" is explicitly signaling that it supports
ALPN negotiation, but that it is not currently configured to support ALPN, but that it is not currently configured to support RADIUS/1.1.
RADIUS/1.1. That information can be used by administrators to That information can be used by administrators to determine which
determine which devices are capable of ALPN. devices are capable of ALPN.
The use of the ALPN string "radius/1.0" also permits server The use of the ALPN string "radius/1.0" also permits server
implementations to send a TLS alert of "no_application_protocol" implementations to send a TLS alert of "no_application_protocol"
(120) when it cannot find a matching ALPN string. Experiments with (120) when it cannot find a matching ALPN string. Experiments with
TLS library implementations suggest that in some cases it is possible TLS library implementations suggest that in some cases it is possible
to send that TLS alert when ALPN is not used. However, such a to send that TLS alert when ALPN is not used. However, such a
scenario is not discussed in [RFC7301] and is likely not universal. scenario is not discussed in [RFC7301] and is likely not universal.
As a result, ALPN as defined in [RFC7301] permits servers to send As a result, ALPN as defined in [RFC7301] permits servers to send
that TLS alert in situations where it would be otherwise forbidden or that TLS alert in situations where it would be otherwise forbidden or
perhaps unsupported. perhaps unsupported.
skipping to change at line 769 skipping to change at line 781
are free to signal support for "radius/1.1" on resumed sessions, even 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 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" free to accept this request and to negotiate the use of "radius/1.1"
for such sessions. for such sessions.
4. RADIUS/1.1 Packet and Attribute Formats 4. RADIUS/1.1 Packet and Attribute Formats
This section describes the application-layer data that is sent inside This section describes the application-layer data that is sent inside
of (D)TLS when using the RADIUS/1.1 protocol. Unless otherwise of (D)TLS when using the RADIUS/1.1 protocol. Unless otherwise
discussed herein, the application-layer data is unchanged from discussed herein, the application-layer data is unchanged from
traditional RADIUS. This protocol is only used when "radius/1.1" has historic RADIUS. This protocol is only used when "radius/1.1" has
been negotiated by both ends of a connection. been negotiated by both ends of a connection.
4.1. RADIUS/1.1 Packet Format 4.1. RADIUS/1.1 Packet Format
When RADIUS/1.1 is used, the RADIUS header is modified from standard When RADIUS/1.1 is used, the RADIUS header is modified from standard
RADIUS. While the header has the same size, some fields have RADIUS. While the header has the same size, some fields have
different meanings. The Identifier and the Request and Response different meanings. The Identifier and the Request and Response
Authenticator fields are no longer used in RADIUS/1.1. Any Authenticator fields are no longer used in RADIUS/1.1. Any
operations that depend on those fields MUST NOT be performed. As operations that depend on those fields MUST NOT be performed. As
packet authentication, secrecy, and security are handled by the TLS packet authentication, secrecy, and security are handled by the TLS
skipping to change at line 1005 skipping to change at line 1017
There are risks from sending passwords over the network, even when There are risks from sending passwords over the network, even when
they are protected by TLS. One such risk comes from the common they are protected by TLS. One such risk comes from the common
practice of multi-hop RADIUS routing. As all security in RADIUS is practice of multi-hop RADIUS routing. As all security in RADIUS is
on a hop-by-hop basis, every proxy that receives a RADIUS packet can on a hop-by-hop basis, every proxy that receives a RADIUS packet can
see (and modify) all of the information in the packet. Sites wishing see (and modify) all of the information in the packet. Sites wishing
to avoid proxies SHOULD use dynamic peer discovery [RFC7585], which to avoid proxies SHOULD use dynamic peer discovery [RFC7585], which
permits clients to make connections directly to authoritative servers permits clients to make connections directly to authoritative servers
for a realm. for a realm.
There are other ways to mitigate these risks. The simplest is to There are other ways to mitigate these risks. The simplest is to
follow the requirements of item (3) from [RFC6614], Section 2.4 and follow the requirements of item (3) from [RFC6614], Section 3.4 and
also follow [RFC7360], Section 10.4, which mandates that RADIUS over also follow [RFC7360], Section 10.4, which mandates that RADIUS over
TLS implementations validate the peer before sending any RADIUS TLS implementations validate the peer before sending any RADIUS
traffic. traffic.
Another way to mitigate these risks is for the system being Another way to mitigate these risks is for the system being
authenticated to use an authentication protocol that never sends authenticated to use an authentication protocol that never sends
passwords (e.g., EAP-pwd [RFC5931]), or one that sends passwords passwords (e.g., an Extensible Authentication Protocol (EAP) method
protected by a TLS tunnel (e.g., EAP-TTLS [RFC5281]). The processes like EAP-pwd [RFC5931]), or one that sends passwords protected by a
to choose and configure an authentication protocol are strongly site TLS tunnel (e.g., EAP Tunneled Transport Layer Security (EAP-TTLS)
dependent, so further discussions of these issues are outside of the [RFC5281]). The processes to choose and configure an authentication
scope of this document. The goal here is to ensure that the reader protocol are strongly site dependent, so further discussions of these
has enough information to make an informed decision. 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 We note that as the RADIUS shared secret is no longer used in this
specification, it is no longer possible or necessary for any specification, it is no longer possible or necessary for any
attribute to be obfuscated on a hop-by-hop basis using the previous attribute to be obfuscated on a hop-by-hop basis using the previous
methods defined for RADIUS. methods defined for RADIUS.
5.1.1. User-Password 5.1.1. User-Password
The User-Password attribute ([RFC2865], Section 5.2) MUST be encoded The User-Password attribute ([RFC2865], Section 5.2) MUST be encoded
the same as any other attribute of data type 'string' ([RFC8044], the same as any other attribute of data type "string" ([RFC8044],
Section 3.5). Section 3.5).
The contents of the User-Password field MUST be at least one octet in The contents of the User-Password field MUST be at least one octet in
length and MUST NOT be more than 128 octets in length. This length and MUST NOT be more than 128 octets in length. This
limitation is maintained from [RFC2865], Section 5.2 for limitation is maintained from [RFC2865], Section 5.2 for
compatibility with historic transports. compatibility with historic transports.
Note that the User-Password attribute is not of data type 'text'. Note that the User-Password attribute is not of data type "text".
The original reason in [RFC2865] was because the attribute was The original reason in [RFC2865] was because the attribute was
encoded as an opaque and obfuscated binary blob. This document does encoded as an opaque and obfuscated binary blob. This document does
not change the data type of User-Password, even though the attribute not change the data type of User-Password, even though the attribute
is no longer obfuscated. The contents of the User-Password attribute is no longer obfuscated. The contents of the User-Password attribute
do not have to be printable text or UTF-8 data as per the definition do not have to be printable text or UTF-8 data as per the definition
of the 'text' data type in [RFC8044], Section 3.4. of the "text" data type in [RFC8044], Section 3.4.
However, implementations should be aware that passwords are often However, implementations should be aware that passwords are often
printable text, and where the passwords are printable text, it can be printable text, and where the passwords are printable text, it can be
useful to store and display them as printable text. Where useful to store and display them as printable text. Where
implementations can process non-printable data in the 'text' data implementations can process non-printable data in the "text" data
type, they MAY use the data type 'text' for User-Password. type, they MAY use the data type "text" for User-Password.
5.1.2. CHAP-Challenge 5.1.2. CHAP-Challenge
[RFC2865], Section 5.3 allows for the CHAP challenge to be taken from [RFC2865], Section 5.3 allows for the CHAP challenge to be taken from
either the CHAP-Challenge attribute ([RFC2865], Section 5.40) or the either the CHAP-Challenge attribute ([RFC2865], Section 5.40) or the
Request Authenticator field. Since RADIUS/1.1 connections no longer Request Authenticator field. Since RADIUS/1.1 connections no longer
use a Request Authenticator field, it is no longer possible to use use a Request Authenticator field, it is no longer possible to use
the Request Authenticator field as the CHAP-Challenge when this the Request Authenticator field as the CHAP-Challenge when this
transport profile is used. transport profile is used.
skipping to change at line 1073 skipping to change at line 1087
RADIUS/1.1 transport and then forward those packets over a RADIUS/1.1 RADIUS/1.1 transport and then forward those packets over a RADIUS/1.1
connection. In that case, if the received Access-Request packet connection. In that case, if the received Access-Request packet
contains a CHAP-Password attribute but no CHAP-Challenge attribute, contains a CHAP-Password attribute but no CHAP-Challenge attribute,
the proxy MUST create a CHAP-Challenge attribute in the proxied the proxy MUST create a CHAP-Challenge attribute in the proxied
packet using the contents from the incoming Request Authenticator of packet using the contents from the incoming Request Authenticator of
the received packet. the received packet.
5.1.3. Tunnel-Password 5.1.3. Tunnel-Password
The Tunnel-Password attribute ([RFC2868], Section 3.5) MUST be The Tunnel-Password attribute ([RFC2868], Section 3.5) MUST be
encoded the same as any other attribute of data type 'string' that encoded the same as any other attribute of data type "string" that
contains a tag, such as Tunnel-Client-Endpoint ([RFC2868], contains a tag, such as Tunnel-Client-Endpoint ([RFC2868],
Section 3.3). Since the attribute is no longer obfuscated in Section 3.3). Since the attribute is no longer obfuscated in
RADIUS/1.1, there is no need for a Salt field or Data-Length fields RADIUS/1.1, there is no need for a Salt field or Data-Length fields
as described in [RFC2868], Section 3.5. The textual value of the as described in [RFC2868], Section 3.5. The textual value of the
password can simply be encoded as is. password can simply be encoded as is.
Note that the Tunnel-Password attribute is not of data type 'text'. Note that the Tunnel-Password attribute is not of data type "text".
The original reason in [RFC2868] was because the attribute was The original reason in [RFC2868] was because the attribute was
encoded as an opaque and obfuscated binary blob. We maintain that encoded as an opaque and obfuscated binary blob. We maintain that
data type here, even though the attribute is no longer obfuscated. data type here, even though the attribute is no longer obfuscated.
The contents of the Tunnel-Password attribute do not have to be The contents of the Tunnel-Password attribute do not have to be
printable text or UTF-8 data as per the definition of the 'text' data printable text or UTF-8 data as per the definition of the "text" data
type in [RFC8044], Section 3.4. type in [RFC8044], Section 3.4.
However, implementations should be aware that passwords are often However, implementations should be aware that passwords are often
printable text, and where the passwords are printable text, it can be printable text, and where the passwords are printable text, it can be
useful to store and display them as printable text. Where useful to store and display them as printable text. Where
implementations can process non-printable data in the 'text' data implementations can process non-printable data in the "text" data
type, they MAY use the data type 'text' for Tunnel-Password. type, they MAY use the data type "text" for Tunnel-Password.
5.1.4. Vendor-Specific Attributes 5.1.4. Vendor-Specific Attributes
Any Vendor-Specific attribute that uses similar obfuscation MUST be Any Vendor-Specific attribute that uses similar obfuscation MUST be
encoded as per their base data type. Specifically, the MS-MPPE-Send- encoded as per their base data type. Specifically, the MS-MPPE-Send-
Key and MS-MPPE-Recv-Key attributes ([RFC2548], Section 2.4) MUST be Key and MS-MPPE-Recv-Key attributes ([RFC2548], Section 2.4) MUST be
encoded as any other attribute of data type 'string' ([RFC8044], encoded as any other attribute of data type "string" ([RFC8044],
Section 3.4). Section 3.4).
5.2. Message-Authenticator 5.2. Message-Authenticator
The Message-Authenticator attribute ([RFC3579], Section 3.2) MUST NOT The Message-Authenticator attribute ([RFC3579], Section 3.2) MUST NOT
be sent over a RADIUS/1.1 connection. That attribute is not used or be sent over a RADIUS/1.1 connection. That attribute is not used or
needed in RADIUS/1.1. needed in RADIUS/1.1.
If the Message-Authenticator attribute is received over a 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 connection, the attribute MUST be silently discarded or treated as an
skipping to change at line 1144 skipping to change at line 1158
The original text in [RFC3579], Section 3.3, Note 1 required that the The original text in [RFC3579], Section 3.3, Note 1 required that the
Message-Authenticator attribute be present for certain Access-Request Message-Authenticator attribute be present for certain Access-Request
packets. It also required the use of the Message-Authenticator when packets. It also required the use of the Message-Authenticator when
the Access-Request packet contained an EAP-Message attribute. the Access-Request packet contained an EAP-Message attribute.
Experience has shown that some RADIUS clients never use the Message- Experience has shown that some RADIUS clients never use the Message-
Authenticator, even for the situations where its use is suggested. Authenticator, even for the situations where its use is suggested.
When the Message-Authenticator attribute is missing from Access- When the Message-Authenticator attribute is missing from Access-
Request packets, it is often possible to trivially forge or replay Request packets, it is often possible to trivially forge or replay
those packets. As such, this document RECOMMENDS that RADIUS clients those packets. As such, it is RECOMMENDED that RADIUS clients always
always include the Message-Authenticator in Access-Request packets include Message-Authenticator in Access-Request packets when using
when using UDP or TCP transport. As the scope of this document is UDP or TCP transport. As the scope of this document is limited to
limited to defining RADIUS/1.1, we cannot mandate that behavior here. defining RADIUS/1.1, we cannot mandate that behavior here. Instead,
Instead, we can note that there are no known negatives to this we can note that there are no known negatives to this behavior, and
behavior, and there are definite positives, such as increased there are definite positives, such as increased security.
security.
5.3. Message-Authentication-Code 5.3. Message-Authentication-Code
Similarly, the Message-Authentication-Code attribute defined in Similarly, the Message-Authentication-Code attribute defined in
[RFC6218], Section 3.3 MUST NOT be sent over a RADIUS/1.1 connection. [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 an "invalid If it is received in a packet, it MUST be treated as an "invalid
attribute" as defined in [RFC6929], Section 2.8. attribute" as defined in [RFC6929], Section 2.8.
As the Message-Authentication-Code attribute is no longer used in As the Message-Authentication-Code attribute is no longer used in
RADIUS/1.1, the related MAC-Randomizer attribute ([RFC6218], 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 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 an "invalid attribute" as received in a packet, it MUST be treated as an "invalid attribute" as
defined in [RFC6929], Section 2.8. defined in [RFC6929], Section 2.8.
5.4. CHAP, MS-CHAP, etc. 5.4. CHAP, MS-CHAP, and Similar Attributes
While some attributes such as CHAP-Password, etc. depend on insecure While some attributes such as CHAP-Password depend on insecure
cryptographic primitives such as MD5, these attributes are treated as cryptographic primitives such as MD5, these attributes are treated as
opaque blobs when sent between a RADIUS client and server. The opaque blobs when sent between a RADIUS client and server. The
contents of the attributes are not obfuscated, and they do not depend contents of the attributes are not obfuscated, and they do not depend
on the RADIUS shared secret. As a result, these attributes are on the RADIUS shared secret. As a result, these attributes are
unchanged in RADIUS/1.1. unchanged in RADIUS/1.1.
Similarly, MS-CHAP depends on MD4, and RADIUS/1.1 does not change the Similarly, MS-CHAP depends on MD4, and RADIUS/1.1 does not change the
definition of any MS-CHAP attributes. However, MS-CHAP has been definition of any MS-CHAP attributes. However, MS-CHAP has been
broken for decades, as noted in [ASLEAP]. The only appropriate use broken for decades, as noted in [ASLEAP]. The only appropriate use
case for MS-CHAP is when it is protected by a secure transport such case for MS-CHAP is when it is protected by a secure transport such
as RADIUS/TLS or RADIUS/DTLS, or when it is used for "inner tunnel" as RADIUS/TLS or RADIUS/DTLS, or when it is used for "inner tunnel"
authentication methods as with the Protected Extensible authentication methods as with the Protected Extensible
Authentication Protocol (PEAP) or TTLS. Authentication Protocol (PEAP) or TTLS.
A server implementing this specification can proxy CHAP, MS-CHAP, A server implementing this specification can proxy and authenticate
etc. without any issue. A server implementing this specification can CHAP, MS-CHAP, etc. without any issue. The RADIUS/1.1 protocol
authenticate CHAP, MS-CHAP, etc. without any issue. The RADIUS/1.1 changes how RADIUS packets are authenticated and how "secret" data is
protocol changes how RADIUS packets are authenticated and how obfuscated inside of a RADIUS packet. It does not change any
"secret" data is obfuscated inside of a RADIUS packet. It does not authentication method that is transported inside of RADIUS.
change any authentication method that is transported inside of
RADIUS.
5.5. Original-Packet-Code 5.5. Original-Packet-Code
[RFC7930], Section 4 defines an Original-Packet-Code attribute. This [RFC7930], Section 4 defines an Original-Packet-Code attribute. This
attribute is needed because otherwise it is impossible to correlate attribute is needed because otherwise it is impossible to correlate
the Protocol-Error response packet with a particular request packet. the Protocol-Error response packet with a particular request packet.
The definition in [RFC7930], Section 4 describes the reasoning behind The definition in [RFC7930], Section 4 describes the reasoning behind
this need: this need:
| The Original-Packet-Code contains the code from the request that | The Original-Packet-Code contains the code from the request that
skipping to change at line 1360 skipping to change at line 1371
seen less adoption, but it is known to be supported in many RADIUS seen less adoption, but it is known to be supported in many RADIUS
clients and servers. clients and servers.
It is RECOMMENDED that all implementations of historic RADIUS/TLS be It is RECOMMENDED that all implementations of historic RADIUS/TLS be
updated to support this specification. Where a system already updated to support this specification. Where a system already
implements RADIUS over TLS, the additional effort to implement this implements RADIUS over TLS, the additional effort to implement this
specification is minimal. Once implementations support it, specification is minimal. Once implementations support it,
administrators can gain the benefit of it with little or no administrators can gain the benefit of it with little or no
configuration changes. This specification is backwards compatible configuration changes. This specification is backwards compatible
with [RFC6614] and [RFC7360]. It is only potentially subject to with [RFC6614] and [RFC7360]. It is only potentially subject to
down-bidding attacks if implementations do not enforce ALPN down-bidding attacks if implementations do not enforce ALPN correctly
negotiation correctly on session resumption. on session resumption.
All crypto-agility needed or used by this specification is All crypto-agility needed or used by this specification is
implemented in TLS. This specification also removes all implemented in TLS. This specification also removes all
cryptographic primitives from the application-layer protocol (RADIUS) cryptographic primitives from the application-layer protocol (RADIUS)
being transported by TLS. As discussed in the following section, being transported by TLS. As discussed in the following section,
this specification also bans the development of all new cryptographic this specification also bans the development of all new cryptographic
or crypto-agility methods in the RADIUS protocol. or crypto-agility methods in the RADIUS protocol.
7.2. Error-Cause Attribute 7.2. Error-Cause Attribute
skipping to change at line 1468 skipping to change at line 1479
insecure link. As RADIUS security and signaling is hop-by-hop, there 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 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 forwarding is taking place. For these reasons and more, it is
therefore inappropriate to define new attributes that are only secure therefore inappropriate to define new attributes that are only secure
if they use a secure transport layer. if they use a secure transport layer.
The result is that specifications do not need to mention this The result is that specifications do not need to mention this
transport profile or make any special provisions for dealing with it. transport profile or make any special provisions for dealing with it.
This specification defines how RADIUS packet encoding, decoding, This specification defines how RADIUS packet encoding, decoding,
authentication, and verification are performed when using RADIUS/1.1. authentication, and verification are performed when using RADIUS/1.1.
So long as any future specification uses the existing encoding, etc. So long as any future specification uses the existing schemes for
schemes defined for RADIUS, no additional text in future documents is encoding, decoding, etc., that are defined for RADIUS, no additional
necessary in order to be compatible with RADIUS/1.1. 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 We note that it is theoretically possible for future standards to
define new cryptographic primitives for use with RADIUS/UDP. In that define new cryptographic primitives for use with RADIUS/UDP. In that
case, those documents would likely have to describe how to transport case, those documents would likely have to describe how to transport
that data in RADIUS/1.1. We believe that such standards are unlikely 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 to be published, as other efforts in the RADEXT Working Group are
forbidding such updates to RADIUS. forbidding such updates to RADIUS.
8. Privacy Considerations 8. Privacy Considerations
This specification requires secure transport for RADIUS. RADIUS/1.1 This specification requires secure transport for RADIUS. RADIUS/1.1
has all of the privacy benefits of RADIUS/TLS [RFC6614] and RADIUS/ has all of the privacy benefits of RADIUS/TLS [RFC6614] and RADIUS/
DTLS [RFC7360] and none of the privacy or security issues of RADIUS/ DTLS [RFC7360] and none of the privacy or security issues of RADIUS/
UDP [RFC2865] or RADIUS/TCP [RFC6613]. UDP [RFC2865] or RADIUS/TCP [RFC6613].
9. Security Considerations 9. Security Considerations
The primary focus of this document is addressing security The primary focus of this document is addressing security
considerations for RADIUS. This specification relies on TLS and considerations for RADIUS. This specification relies on TLS and
associated ALPN negotiation for much of its security. We refer the associated ALPN for much of its security. We refer the reader to
reader to [RFC8446] and [RFC7360] for discussions of the security of [RFC8446] and [RFC7360] for discussions of the security of those
those protocols. The discussion in this section is limited to issues protocols. The discussion in this section is limited to issues
unique to this specification. unique to this specification.
Implementations should rely on the underlying TLS library to perform Implementations should rely on the underlying TLS library to perform
ALPN version negotiation. That is, implementations should supply a ALPN version negotiation. That is, implementations should supply a
list of permitted ALPN strings to the TLS library, and let it return list of permitted ALPN strings to the TLS library, and let it return
the negotiated value. the negotiated value.
There are few other opportunities for security issues. If an There are few other opportunities for security issues. If an
implementation gets ALPN negotiation wrong, then the wrong implementation gets ALPN wrong, then the wrong application data will
application data will be transported inside of TLS. While RADIUS/1.0 be transported inside of TLS. While RADIUS/1.0 and RADIUS/1.1 share
and RADIUS/1.1 share similar packet formats, the protocols are not similar packet formats, the protocols are not mutually compatible.
mutually compatible.
When an implementation receives the packets for a RADIUS version that When an implementation receives the packets for a RADIUS version that
is not supported by this connection, it will not be able to process is not supported by this connection, it will not be able to process
the packets. Implementations can produce log messages indicating the packets. Implementations can produce log messages indicating
that the application-layer data is unexpected and close the that the application-layer data is unexpected and close the
connection. In addition, the implementations that see the incorrect connection. In addition, the implementations that see the incorrect
application data already have full access to all secrets, passwords, application data already have full access to all secrets, passwords,
etc. being transported, so any protocol differences do not result in etc. being transported, so any protocol differences do not result in
any security issues. Since all of the application data is protected any security issues. Since all of the application data is protected
by TLS, there is no possibility for an attacker to obtain any extra by TLS, there is no possibility for an attacker to obtain any extra
skipping to change at line 1619 skipping to change at line 1630
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
11.2. Informative References 11.2. Informative References
[ASLEAP] "asleap - recovers weak LEAP and PPTP passwords", commit [ASLEAP] "asleap - recovers weak LEAP and PPTP passwords", commit
254acab, November 2020, 254acab, November 2020,
<https://github.com/joswr1ght/asleap>. <https://github.com/joswr1ght/asleap>.
[EDUROAM] eduroam, "eduroam", <https://eduroam.org>. [EDUROAM] eduroam, "eduroam", <https://eduroam.org>.
[FIPS-140-3]
NIST, "Security Requirements for Cryptographic Modules",
NIST FIPS 140-3, DOI 10.6028/NIST.FIPS.140-3, March 2019,
<https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.140-3.pdf>.
[OPENROAMING] [OPENROAMING]
Wireless Broadband Alliance, "OpenRoaming: One global Wi- Wireless Broadband Alliance, "OpenRoaming: One global Wi-
Fi network", <https://wballiance.com/openroaming/>. Fi network", <https://wballiance.com/openroaming/>.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
DOI 10.17487/RFC1321, April 1992, DOI 10.17487/RFC1321, April 1992,
<https://www.rfc-editor.org/info/rfc1321>. <https://www.rfc-editor.org/info/rfc1321>.
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes",
RFC 2548, DOI 10.17487/RFC2548, March 1999, RFC 2548, DOI 10.17487/RFC2548, March 1999,
 End of changes. 49 change blocks. 
120 lines changed or deleted 137 lines changed or added

This html diff was produced by rfcdiff 1.48.