rfc9765.original   rfc9765.txt 
RADEXT Working Group A. DeKok Internet Engineering Task Force (IETF) A. DeKok
Internet-Draft FreeRADIUS Request for Comments: 9765 FreeRADIUS
Updates: 2865, 2866, 5176, 6613, 6614, 7360 (if 18 October 2024 Updates: 2865, 2866, 5176, 6613, 6614, 7360 April 2025
approved) Category: Experimental
Intended status: Experimental ISSN: 2070-1721
Expires: 21 April 2025
RADIUS/1.1, Leveraging ALPN to remove MD5 RADIUS/1.1: Leveraging Application-Layer Protocol Negotiation (ALPN) to
draft-ietf-radext-radiusv11-11 Remove MD5
Abstract Abstract
This document defines Application-Layer Protocol Negotiation This document defines Application-Layer Protocol Negotiation (ALPN)
Extensions for use with RADIUS/TLS and RADIUS/DTLS. These extensions extensions for use with RADIUS/TLS and RADIUS/DTLS. These extensions
permit the negotiation of an application protocol variant of RADIUS, permit the negotiation of an application protocol variant of RADIUS
called "RADIUS/1.1". No changes are made to RADIUS/UDP or RADIUS/ called "RADIUS/1.1". No changes are made to RADIUS/UDP or RADIUS/
TCP. The extensions allow the negotiation of a transport profile TCP. The extensions allow the negotiation of a transport profile
where the RADIUS shared secret is no longer used, and all MD5-based where the RADIUS shared secret is no longer used, and all MD5-based
packet authentication and attribute obfuscation methods are removed. packet authentication and attribute obfuscation methods are removed.
This document updates RFC2865, RFC2866, RFC5176, RFC6613, RFC6614, This document updates RFCs 2865, 2866, 5176, 6613, 6614, and 7360.
and RFC 7360.
About This Document
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-ietf-radext-radiusv11/.
Discussion of this document takes place on the RADEXT Working Group
mailing list (mailto:radext@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/radext/. Subscribe at
https://www.ietf.org/mailman/listinfo/radext/.
Source for this draft and an issue tracker can be found at
https://github.com/radext-wg/draft-ietf-radext-radiusv11.git.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for examination, experimental implementation, and
evaluation.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document defines an Experimental Protocol for the Internet
and may be updated, replaced, or obsoleted by other documents at any community. This document is a product of the Internet Engineering
time. It is inappropriate to use Internet-Drafts as reference Task Force (IETF). It represents the consensus of the IETF
material or to cite them other than as "work in progress." community. It has received public review and has been approved for
publication by the Internet Engineering Steering Group (IESG). Not
all documents approved by the IESG are candidates for any level of
Internet Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on 21 April 2025. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9765.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Terminology
3. The RADIUS/1.1 Transport profile for RADIUS . . . . . . . . . 8 3. The RADIUS/1.1 Transport Profile for RADIUS
3.1. ALPN Name for RADIUS/1.1 . . . . . . . . . . . . . . . . 8 3.1. ALPN Name for RADIUS/1.1
3.2. Operation of ALPN . . . . . . . . . . . . . . . . . . . . 9 3.2. Operation of ALPN
3.3. Configuration of ALPN for RADIUS/1.1 . . . . . . . . . . 10 3.3. Configuration of ALPN for RADIUS/1.1
3.3.1. Using Protocol-Error for Signaling ALPN Failure . . . 14 3.3.1. Using Protocol-Error for Signaling ALPN Failure
3.3.2. Tabular Summary . . . . . . . . . . . . . . . . . . . 14 3.3.2. Tabular Summary
3.4. Miscellaneous Items . . . . . . . . . . . . . . . . . . . 16 3.4. Miscellaneous Items
3.5. Session Resumption . . . . . . . . . . . . . . . . . . . 16 3.5. Session Resumption
4. RADIUS/1.1 Packet and Attribute Formats . . . . . . . . . . . 17 4. RADIUS/1.1 Packet and Attribute Formats
4.1. RADIUS/1.1 Packet Format . . . . . . . . . . . . . . . . 17 4.1. RADIUS/1.1 Packet Format
4.2. The Token Field . . . . . . . . . . . . . . . . . . . . . 19 4.2. The Token Field
4.2.1. Sending Packets . . . . . . . . . . . . . . . . . . . 19 4.2.1. Sending Packets
4.2.2. Receiving Packets . . . . . . . . . . . . . . . . . . 21 4.2.2. Receiving Packets
5. Attribute handling . . . . . . . . . . . . . . . . . . . . . 22 5. Attribute Handling
5.1. Obfuscated Attributes . . . . . . . . . . . . . . . . . . 22 5.1. Obfuscated Attributes
5.1.1. User-Password . . . . . . . . . . . . . . . . . . . . 23 5.1.1. User-Password
5.1.2. CHAP-Challenge . . . . . . . . . . . . . . . . . . . 23 5.1.2. CHAP-Challenge
5.1.3. Tunnel-Password . . . . . . . . . . . . . . . . . . . 24 5.1.3. Tunnel-Password
5.1.4. Vendor-Specific Attributes . . . . . . . . . . . . . 24 5.1.4. Vendor-Specific Attributes
5.2. Message-Authenticator . . . . . . . . . . . . . . . . . . 24 5.2. Message-Authenticator
5.3. Message-Authentication-Code . . . . . . . . . . . . . . . 26 5.3. Message-Authentication-Code
5.4. CHAP, MS-CHAP, etc. . . . . . . . . . . . . . . . . . . . 26 5.4. CHAP, MS-CHAP, and Similar Attributes
5.5. Original-Packet-Code . . . . . . . . . . . . . . . . . . 26 5.5. Original-Packet-Code
6. Other Considerations When Using ALPN
6. Other Considerations when using ALPN . . . . . . . . . . . . 27 6.1. Protocol-Error
6.1. Protocol-Error . . . . . . . . . . . . . . . . . . . . . 27 6.2. Status-Server
6.2. Status-Server . . . . . . . . . . . . . . . . . . . . . . 29 6.3. Proxies
6.3. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . 29 7. Other RADIUS Considerations
7. Other RADIUS Considerations . . . . . . . . . . . . . . . . . 29 7.1. Crypto-Agility
7.1. Crypto-Agility . . . . . . . . . . . . . . . . . . . . . 30 7.2. Error-Cause Attribute
7.2. Error-Cause Attribute . . . . . . . . . . . . . . . . . . 30 7.3. Future Standards
7.3. Future Standards . . . . . . . . . . . . . . . . . . . . 31 8. Privacy Considerations
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 33 9. Security Considerations
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 33 10. IANA Considerations
10. Security Considerations . . . . . . . . . . . . . . . . . . . 33 11. References
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 11.1. Normative References
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 11.2. Informative References
13. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Acknowledgments
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 Author's Address
14.1. Normative References . . . . . . . . . . . . . . . . . . 38
14.2. Informative References . . . . . . . . . . . . . . . . . 39
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction 1. Introduction
The RADIUS protocol [RFC2865] uses MD5 [RFC1321] to authenticate The RADIUS protocol [RFC2865] uses MD5 [RFC1321] to authenticate
packets, and to obfuscate certain attributes. Additional transport packets and to obfuscate certain attributes. Additional transport
protocols were defined for TCP ([RFC6613]), TLS ([RFC6614]), and DTLS protocols were defined for TCP [RFC6613], TLS [RFC6614], and DTLS
([RFC7360]). However, those transport protocols still use MD5 to [RFC7360]. However, those transport protocols still use MD5 to
authenticate individual packets. That is, the shared secret was used authenticate individual packets. That is, the shared secret was used
along with MD5, even when the RADIUS packets were being transported along with MD5, even when the RADIUS packets were being transported
in (D)TLS. At the time, the consensus of the RADEXT working group in (D)TLS. At the time, the consensus of the RADEXT Working Group
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 most notably Issues of MD5 security have been known for decades, most notably in
in [RFC6151], and in [RFC6421], Section 3, among others. The [RFC6151] and in Section 3 of [RFC6421], among others. The reliance
reliance on MD5 for security makes it impossible to use RADIUS in on MD5 for security makes it impossible to use RADIUS in secure
secure systems which forbid the use of digest algorithms with known systems that forbid the use of digest algorithms with known
vunerabilities. 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
cryprographic 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 there 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 which 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 be 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 which 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 best be 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 whole-sale revision of the RADIUS RADIUS over TLS, rather than a wholesale revision of the RADIUS
protocol. protocol.
Systems which 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, which are: on top of an existing RADIUS/TLS server implementation. These
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.
* After the TLS handshake has completed, a method to query if ALPN * A method to query if ALPN has chosen a protocol (and if yes, which
has chosen a protocol, and if yes, which protocol was chosen. protocol was chosen) after the TLS handshake has completed.
* Changes to the packet encoder and decoder, so that the individual * Changes to the packet encoder and decoder, so that the individual
packets are not authenticated, and no attribute is encoded with packets are not authenticated, and no attribute is encoded with
the historic obfuscation methods. the historic obfuscation methods.
That is, the bulk of the ALPN protocol can be left to the underlying That is, the bulk of the ALPN protocol can be left to the underlying
TLS implementation. This document discusses the ALPN exchange in TLS implementation. This document discusses the ALPN exchange in
detail in order to give simplified descriptions for the reader, and detail in order to give simplified descriptions for the reader, and
so that the reader does not have to read or understand all of so that the reader does not have to read or understand all of
[RFC7301]. [RFC7301].
The detailed list of changes from historic TLS-based transports to The detailed list of changes from historic TLS-based transports to
RADIUS/1.1 is as follows: RADIUS/1.1 is as follows:
* ALPN is used for negotiation of this extension, * ALPN is used for negotiation of this extension.
* TLS 1.3 or later is required, * TLS 1.3 or later is required.
* All uses of the RADIUS shared secret have been removed, * All uses of the RADIUS shared secret have been removed.
* The now-unused Request and Response Authenticator fields have been
repurposed to carry an opaque Token which identifies requests and * The now unused Request and Response Authenticator fields have been
responses, repurposed to carry an opaque Token that identifies requests and
responses.
* The functionality of the Identifier field has been replaced by the * The functionality of the Identifier field has been replaced by the
Token field, and the space previously taken by the Identifier Token field, and the space previously taken by the Identifier
field is now reserved and unused, field is now reserved and unused.
* The Message-Authenticator attribute ([RFC3579], Section 3.2) is * The Message-Authenticator attribute ([RFC3579], Section 3.2) is
not sent in any packet, and if received is ignored, not sent in any packet, and is ignored if received.
* Attributes such as User-Password, Tunnel-Password, and MS-MPPE * Attributes such as User-Password, Tunnel-Password, and MS-MPPE
keys are sent encoded as "text" ([RFC8044], Section 3.4) or keys are sent encoded as "text" ([RFC8044], Section 3.4) or
"octets" ([RFC8044], Section 3.5), without the previous MD5-based "octets" ([RFC8044], Section 3.5), without the previous MD5-based
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 which have simple encodings (that is, attributes * All attributes that have simple encodings (that is, attributes
which 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 which 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) which * 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 which implements A major benefit of this extension is that a server that implements it
it can also be more easily verified for FIPS-140 compliance. That can also be more easily verified for FIPS 140 compliance. That is, a
is, a server can remove all uses of MD5, which means that those server can remove all uses of MD5, which means that those algorithms
algorithms are provably not used for security purposes. In that are provably not used for security purposes. In that case, however,
case, however, the server will not support CHAP, or any the server will not support the Challenge Handshake Authentication
authentication method which uses MD5. The choice of which Protocol (CHAP) or any authentication method that uses MD5. The
authentication method to accept is always left to the server. This choice of which authentication method to accept is always left to the
specification does not change any authentication method carried in server. This specification does not change any authentication method
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 MS-CHAP authentication. So far as a proxy is concerned, CHAP or Microsoft CHAP (MS-CHAP) authentication. So far as a proxy
attributes relating to CHAP and MS-CHAP are simply opaque data that is concerned, attributes relating to CHAP and MS-CHAP are simply
is transported unchanged to the next hop. It is therefore possible opaque data that is transported unchanged to the next hop.
for a FIPS-140 compliant proxy to transport authentication methods Therefore, it is possible for a FIPS 140 compliant proxy to transport
which depend on MD5, so long as that data is forwarded to a server authentication methods that depend on MD5, so long as that data is
which supports those methods. forwarded to a server that supports those methods.
We reiterate that the decision to support (or not) any authentication We reiterate that the decision to support (or not support) any
method is entirely site local, and is not a requirement of this authentication method is entirely site local, and is not a
specification. The contents or meaning of any RADIUS attribute other requirement of this specification. The contents or meaning of any
than Message-Authenticator (and similar attributes) are not modified. RADIUS attribute other than the Message-Authenticator (and similar
The only change to the Message-Authenticator attribute is that it is attributes) are not modified. The only change to the Message-
no longer used in RADIUS/1.1. Authenticator attribute is that it is no longer used in RADIUS/1.1.
Unless otherwise described in this document, all RADIUS requirements Unless otherwise described in this document, all RADIUS requirements
apply to this extension. That is, this specification defines a apply to this extension. That is, this specification defines a
transport profile for RADIUS. It is not an entirely new protocol, transport profile for RADIUS. It is not an entirely new protocol,
and it defines only minor changes to the existing RADIUS protocol. and it defines only minor changes to the existing RADIUS protocol.
It does not change the RADIUS packet format, attribute format, etc. It does not change the RADIUS packet format, attribute format, etc.
This specification is compatible with all RADIUS attributes, past, This specification is compatible with all RADIUS attributes of the
present, and future. past, present, and future.
This specification is compatible with existing implementations of This specification is compatible with existing implementations of
RADIUS/TLS and RADIUS/DTLS. Systems which implement this standard RADIUS/TLS and RADIUS/DTLS. Systems that implement this
can fall back to historic RADIUS/TLS if no ALPN signaling is specification can fall back to historic RADIUS/TLS if no ALPN
performed, and the local configuration permits such fallback. signaling is performed, and the local configuration permits such
fallback.
This specification is compatible with all existing RADIUS This specification is compatible with all existing RADIUS
specifications. There is no need for any RADIUS specification to specifications. There is no need for any RADIUS specification to
mention this transport profile by name, or to make provisions for mention this transport profile by name or to make provisions for this
this specification. This document defines how to transform RADIUS specification. This document defines how to transform RADIUS into
into RADIUS/1.1, and no further discussion of that transformation is RADIUS/1.1, and no further discussion of that transformation is
necessary. necessary.
We note that this document makes no changes to previous RADIUS We note that this document makes no changes to previous RADIUS
specifications. Existing RADIUS implementations can continue to be specifications. Existing RADIUS implementations can continue to be
used without modification. Where previous specifications are used without modification. Where previous specifications are
explicitly mentioned and updated, those updates or changes apply only explicitly mentioned and updated, those updates or changes apply only
when the RADIUS/1.1 transport profile is being used. when the RADIUS/1.1 transport profile is being used.
In short, when negotiated on a connection, the RADIUS/1.1 transport In short, when negotiated on a connection, the RADIUS/1.1 transport
profile permits implementations to avoid MD5 when authenticating profile permits implementations to avoid MD5 when authenticating
packets, or when obfuscating certain attributes. packets or when obfuscating certain attributes.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
The following list describes the terminology and abbreviations which The following list describes the terminology and abbreviations that
are used in this document. are used in this document.
* ALPN ALPN
Application-Layer Protocol Negotiation (as defined in [RFC7301]).
Application-Layer Protocol Negotiation, as defined in [RFC7301].
* RADIUS
The Remote Authentication Dial-In User Service protocol, as RADIUS
defined in [RFC2865], [RFC2866], and [RFC5176] among others. Remote Authentication Dial-In User Service (as defined in
[RFC2865], [RFC2866], and [RFC5176], among others).
While this protocol can be viewed as "RADIUS/1.0", for simplicity While this protocol can be viewed as "RADIUS/1.0", for simplicity
and historical compatibility, we keep the name "RADIUS". and historical compatibility, we keep the name "RADIUS".
* RADIUS/UDP RADIUS/UDP
RADIUS over the User Datagram Protocol (see [RFC2865], [RFC2866],
RADIUS over the User Datagram Protocol [RFC2865], [RFC2866], and [RFC5176], among others).
[RFC5176], among others.
* RADIUS/TCP
RADIUS/TCP
RADIUS over the Transmission Control Protocol [RFC6613]. RADIUS over the Transmission Control Protocol [RFC6613].
* RADIUS/TLS RADIUS/TLS
RADIUS over Transport Layer Security [RFC6614].
RADIUS over the Transport Layer Security protocol [RFC6614].
* RADIUS/DTLS
RADIUS over the Datagram Transport Layer Security protocol
[RFC7360].
* RADIUS over TLS
Any RADIUS packets transported over TLS or DTLS. This terminology
is used instead of alternatives such as "RADIUS/(D)TLS", or
"either RADIUS/TLS or RADIUS/DTLS". This term is generally used
when referring to TLS-layer requirements for RADIUS packet
transport.
* historic RADIUS/TLS
RADIUS over (D)TLS as defined in [RFC6614] and [RFC7360]. This
term does not include the protocol defined in this specification.
* RADIUS/1.1 RADIUS/DTLS
RADIUS over Datagram Transport Layer Security [RFC7360].
The transport profile defined in this document, which stands for RADIUS over TLS
"RADIUS version 1.1". We use RADIUS/1.1 to refer interchangeably Refers to any RADIUS packets transported over TLS or DTLS. This
to TLS and DTLS transport. terminology is used instead of alternatives such as
"RADIUS/(D)TLS" or "either RADIUS/TLS or RADIUS/DTLS". This term
is generally used when referring to TLS-layer requirements for
RADIUS packet transport.
* TLS historic RADIUS/TLS
Refers to RADIUS over (D)TLS (as defined in [RFC6614] and
[RFC7360]). This term does not include the protocol defined in
this specification.
The Transport Layer Security protocol. Generally when we refer to RADIUS/1.1
TLS in this document, we are referring interchangeably to TLS or RADIUS version 1.1, i.e., the transport profile defined in this
document. We use RADIUS/1.1 to refer interchangeably to TLS and
DTLS transport. DTLS transport.
3. The RADIUS/1.1 Transport profile for RADIUS TLS
Transport Layer Security. Generally, when we refer to TLS in this
document, we are referring interchangeably to TLS or DTLS
transport.
3. The RADIUS/1.1 Transport Profile for RADIUS
This section describes the ALPN transport profile in detail. It This section describes the ALPN transport profile in detail. It
first gives the name used for ALPN, and then describes how ALPN is first gives the name used for ALPN, and then describes how ALPN is
configured and negotiated by client and server. It then concludes by configured and negotiated by the client and server. It then
discussing TLS issues such as what to do for ALPN during session concludes by discussing TLS issues such as what to do for ALPN during
resumption. session resumption.
3.1. ALPN Name for RADIUS/1.1 3.1. ALPN Name for RADIUS/1.1
The ALPN name defined for RADIUS/1.1 is as follows: The ALPN name defined for RADIUS/1.1 is as follows:
"radius/1.1" "radius/1.1"
The protocol defined by this specification.
The protocol defined by this specification.
Where ALPN is not configured or is not received in a TLS connection, Where ALPN is not configured or is not received in a TLS connection,
systems supporting ALPN MUST NOT use RADIUS/1.1. systems supporting ALPN MUST NOT use RADIUS/1.1.
Where ALPN is configured, the client signals support by sending ALPN Where ALPN is configured, the client signals support by sending ALPN
strings listing which protocols it supports. The server can accept strings listing which protocols it supports. The server can accept
one of these proposals and reply with a matching ALPN string, or one of these proposals and reply with a matching ALPN string, or
reject this proposal, and not reply with any ALPN string. A full reject this proposal and not reply with any ALPN string. A full
walk-through of the protocol negotiation is given below. walkthrough of the protocol negotiation is given below.
Implementations MUST signal ALPN "radius/1.1" in order for it to be Implementations MUST signal ALPN "radius/1.1" in order for it to be
used in a connection. used in a connection.
The next step in defining RADIUS/1.1 is to review how ALPN works. The next step in defining RADIUS/1.1 is to review how ALPN works.
3.2. Operation of ALPN 3.2. Operation of ALPN
In order to provide a high-level description of ALPN for readers who 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 are not familiar with the details of [RFC7301], we provide a brief
overview here. overview here.
Once a system has been configured to support ALPN, it is negotiated Once a system has been configured to support ALPN, it is negotiated
on a per-connection basis as per [RFC7301]. The negotiation proceeds on a per-connection basis as per [RFC7301]. The negotiation proceeds
as follows: as follows:
1) The client sends an ALPN extension in the ClientHello. This 1) The client sends an ALPN extension in the ClientHello. This
extension lists one or more application protocols by name. These extension lists one or more application protocols by name. These
names are the protocols which the client is claiming to support. names are the protocols that the client is claiming to support.
2) The server receives the extension, and validates the application 2) The server receives the extension and validates the application
protocol name(s) against the list it has configured. protocol name(s) against the list it has configured.
If the server finds no acceptable common protocols (ALPN or If the server finds no acceptable common protocols (ALPN or
otherwise), it closes the connection. otherwise), it closes the connection.
3) Otherwise, the server returns a ServerHello with either no ALPN 3) Otherwise, the server returns a ServerHello with either no ALPN
extension, or an ALPN extension containing only one named application extension or an ALPN extension containing only one named
protocol, which needs to be one of the names proposed by the client. 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 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. the ALPN proposal, the server does not reply with any ALPN name.
4) The client receives the ServerHello, validates the received 4) The client receives the ServerHello, validates the received
application protocol (if any) against the name(s) it sent, and application protocol (if any) against the name(s) it sent, and
records which application protocol was chosen. records which application protocol was chosen.
This check is necessary in order for the client to both know which This check is necessary in order for the client to both know
protocol the server has selected, and to validate that the which protocol the server has selected, and to validate that the
protocol sent by the server is one which is acceptable to the protocol sent by the server is one that is acceptable to the
client. client.
The next step in defining RADIUS/1.1 is to define how ALPN is 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 configured on the client and server and to give more detailed
requirements on its configuration and operation. requirements on its configuration and operation.
3.3. Configuration of ALPN for RADIUS/1.1 3.3. Configuration of ALPN for RADIUS/1.1
Clients or servers supporting this specification can do so by Clients or servers supporting this specification can do so by
extending their TLS configuration through the addition of a new extending their TLS configuration through the addition of a new
configuration variable, called "Version" here. The exact name given configuration variable, called "Version" here. The exact name given
below does not need to be used, but it is RECOMMENDED that below does not need to be used, but it is RECOMMENDED that
administrative interfaces or programming interfaces use a similar administrative interfaces or programming interfaces use a similar
name in order to provide consistent terminology. This variable name in order to provide consistent terminology. This variable
controls how the implementation signals use of this protocol via controls how the implementation signals use of this protocol via
ALPN. ALPN.
When set, this variable should contain the list of permitted RADIUS When set, this variable should contain the list of permitted RADIUS
versions as numbers, e.g. "1.0" or "1.1". The implementation may versions as numbers, e.g., "1.0" or "1.1". The implementation may
allow multiple values in one variable, or allow multiple variables, allow multiple values in one variable, allow multiple variables, or
or instead use two configuration for "minimum" and "maximum" allowed instead use two configurations for the "minimum" and "maximum"
versions. We assume here that there is one variable, which can allowed versions. We assume here that there is one variable, which
contain either no value, or else a list of one or more versions which can contain either no value or a list of one or more versions that
the current implementation supports. In this specification, the the current implementation supports. In this specification, the
possible values, ALPN strings, and corresponding interpretations are: possible values, ALPN strings, and corresponding interpretations are:
Value | ALPN String(s) | Interpretation +==========+========================+=============================+
------------------------------------------------------ | Value | ALPN String(s) | Interpretation |
unset | | no ALPN strings are sent. +==========+========================+=============================+
1.0 | radius/1.0 | require historic RADIUS/TLS | unset | | no ALPN strings are sent |
1.0, 1.1 | radius/1.0, radius/1.1 | allow either historic +----------+------------------------+-----------------------------+
| | RADIUS/TLS or RADIUS/1.1. | 1.0 | radius/1.0 | require historic RADIUS/TLS |
1.1 | radius/1.1 | require RADIUS/1.1. +----------+------------------------+-----------------------------+
| 1.0, 1.1 | radius/1.0, radius/1.1 | allow either historic |
| | | RADIUS/TLS or RADIUS/1.1 |
+----------+------------------------+-----------------------------+
| 1.1 | radius/1.1 | require RADIUS/1.1 |
+----------+------------------------+-----------------------------+
Table 1
This configuration is also extensible to future RADIUS versions if This configuration is also extensible to future RADIUS versions if
that extension becomes necessary. New values and ALPN names can that extension becomes necessary. New values and ALPN names can
simply be added to the list. Implementations can then negotiate the simply be added to the list. Implementations can then negotiate the
highest version which is supported by both client and server. highest version that is supported by both client and server.
Implementations SHOULD support both historic RADIUS/TLS and Implementations SHOULD support both historic RADIUS/TLS and
RADIUS/1.1. Such implementations MUST set the default value for this RADIUS/1.1. Such implementations MUST set the default value for this
configuration variable to "1.0, 1.1". This setting ensures that both configuration variable to "1.0, 1.1". This setting ensures that both
versions of RADIUS can be negotiated. versions of RADIUS can be negotiated.
Implementations MAY support only RADIUS/1.1. In which case the Implementations MAY support only RADIUS/1.1. In this case, the
default value for this configuration variable MUST be "1.1". This default value for this configuration variable MUST be "1.1". This
behavior is NOT RECOMMENDED, as it is incompatible with historic behavior is NOT RECOMMENDED, as it is incompatible with historic
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
skipping to change at page 11, line 9 skipping to change at line 465
default value for this configuration variable MUST be "1.1". This default value for this configuration variable MUST be "1.1". This
behavior is NOT RECOMMENDED, as it is incompatible with historic behavior is NOT RECOMMENDED, as it is incompatible with historic
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":
A. If unset, ALPN is not used.
When the variable is unset, ALPN is not used.
Any connection MUST use historic RADIUS/TLS.
This variable 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 Any connection MUST use historic RADIUS/TLS.
The server MUST NOT signal any protocol name via ALPN. This variable 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 of performing ALPN negotiation,
even if it is not currently configured to use RADIUS/1.1.
If the server receives an ALPN name from the client, it MUST Client Behavior
NOT close the connection. Instead, it simply does not reply The client MUST NOT send any protocol name via ALPN.
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 Server Behavior
see that the server failed to acknowledge this request, and The server MUST NOT signal any protocol name via ALPN.
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.) 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.
Client Behavior 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.
The client MUST send the ALPN string(s) associated with the B. If set to "1.0", "1.0, 1.1", "1.1", or future values:
configured version. e.g. For "1.0", send "radius/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
connection as using the matching ALPN version.
If the server receives no ALPN name from the client, it MUST Server Behavior
use historic RADIUS/TLS. 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 If the server receives one or more ALPN names from the
client, it MUST reply with the highest mutually supported client, it MUST reply with the highest mutually supported
version and then use the latest supported version for this version and then use the latest supported version for this
connection. connection.
If the server receives one or more ALPN names from the If the server receives one or more ALPN names from the
client, but none of the names match the versions supported client, but none of the names match the versions supported
by (or configured on) the server, it MUST reply with a TLS by (or configured on) the server, it MUST reply with a TLS
alert of "no_application_protocol" (120), and then MUST alert of "no_application_protocol" (120), and then it MUST
close the TLS connection. close the TLS connection.
These requirements for negotiation are not specific to These requirements for negotiation are not specific to
RADIUS/1.1, and therefore can be used unchanged if any new RADIUS/1.1; therefore, they can be used unchanged if any
version of RADIUS is defined. 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 setting that forbid RADIUS/1.1, will behave are configured with settings that forbid RADIUS/1.1, will behave
largely the same as systems which do not implement this largely the same as systems that do not implement this specification.
specification. The only difference is that clients may send the ALPN The only difference is that clients may send the ALPN name
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
their own deployments. their own deployments.
While [RFC7301] does not discuss the possibility of the server While [RFC7301] does not discuss the possibility of the server
sending a TLS alert of "no_application_protocol" (120) when the sending a TLS alert of "no_application_protocol" (120) when the
client does not use ALPN, this behavior appears to be useful. As client does not use ALPN, this behavior appears to be useful. As
such, servers MAY send a a TLS alert of "no_application_protocol" such, servers MAY send a TLS alert of "no_application_protocol" (120)
(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 not be able to determine why that failure the connection fails, but it may not be able to determine why that
has occurred. Implementers and administrators should be aware that failure has occurred. Implementers and administrators should be
unexplained connection failures may be due to ALPN negotiation aware that unexplained connection failures may be due to ALPN issues.
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).
Whether or not the server sent a TLS alert for no compatible ALPN, it The server MUST close the connection whether or not the server sent a
MUST close the connection. The above requirements on ALPN apply to TLS alert for no compatible ALPN. The above requirements on ALPN
both new sessions, and to resumed sessions. apply to both new sessions and to resumed sessions.
In contrast, there is no need for the client to signal that there are In contrast, there is no need for the client to signal that there are
no compatible application protocol names. The client sends zero or no compatible application protocol names. The client sends zero or
more protocol names, and the server responds as above. From the 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 point of view of the client, the list it sent results in either a
connection failure, or a connection success. connection failure or a connection success.
It is RECOMMENDED that the server logs a descriptive error in this It is RECOMMENDED that the server logs a descriptive error in this
situation, so that an administrator can determine why a particular situation, so that an administrator can determine why a particular
connection failed. The log message SHOULD include information about connection failed. The log message SHOULD include information about
the other end of the connection, such as IP address, certificate the other end of the connection, such as the IP address, certificate
information, etc. Similarly, when the client receives a TLS alert of information, etc. Similarly, when the client receives a TLS alert of
"no_application_protocol" it SHOULD log a descriptive error message. "no_application_protocol" (120), it SHOULD log a descriptive error
Such error messages are critical for helping administrators to message. Such error messages are critical for helping administrators
diagnose connectivity issues. diagnose connectivity issues.
3.3.1. Using Protocol-Error for Signaling ALPN Failure 3.3.1. Using Protocol-Error for Signaling ALPN Failure
When it is not possible to send a TLS alert of When it is not possible to send a TLS alert of
"no_application_protocol" (120), then the only remaining method for "no_application_protocol" (120), then the only remaining method for
one party to signal the other is to send application data inside of one party to signal the other is to send application data inside of
the TLS tunnel. Therefore, for the situation when a one end of a the TLS tunnel. Therefore, for the situation when one end of a
connection determines that it requires ALPN while the other end does connection determines that it requires ALPN, while the other end does
not support ALPN, the end requiring ALPN MAY send a Protocol-Error not support ALPN, then the end requiring ALPN MAY send a Protocol-
packet [RFC7930] inside of the tunnel, and then MUST close the Error packet [RFC7930] inside of the tunnel and then MUST close the
connection. If this is done, the Token field of the Protocol-Error connection. If this is done, the Token field of the Protocol-Error
packet cannot be copied from any request, and therefore that field packet cannot be copied from any request; therefore, that field MUST
MUST be set to all zeros. be set to all zeros.
The Protocol-Error packet SHOULD contain a Reply-Message attribute The Protocol-Error packet SHOULD contain a Reply-Message attribute
with a textual string describing the cause of the error. The packet with a textual string describing the cause of the error. The packet
SHOULD also contain an Error-Cause attribute, with value Unsupported SHOULD also contain an Error-Cause attribute, with value 406
Extension (406). The packet SHOULD NOT contain other attributes. (Unsupported Extension). The packet SHOULD NOT contain other
attributes.
An implementation sending this packet could bypass any RADIUS An implementation sending this packet could bypass any RADIUS encoder
encoder, and simply write this packet as a predefined, fixed set of and simply write this packet as a predefined, fixed set of data to
data to the TLS connection. That process would likely be simpler the TLS connection. That process would likely be simpler than trying
than trying to call the normal RADIUS packet encoder to encode a to call the normal RADIUS packet encoder to encode a reply packet
reply packet with no corresponding request packet. with no corresponding request packet.
As this packet is an unexpected response packet, existing client As this packet is an unexpected response packet, existing client
implementations of RADIUS over TLS will ignore it. They may either implementations of RADIUS over TLS will ignore it. They may either
log an error and close the connection, or they may discard the packet log an error and close the connection, or they may discard the packet
and leave the connection open. If the connection remains open, the and leave the connection open. If the connection remains open, the
end supporting ALPN will close the connection, so there will be no end supporting ALPN will close the connection, so there will be no
side effects from sending this packet. Therefore, while using a side effects from sending this packet. Therefore, while using a
Protocol-Error packet in this way is unusual, it is both informative Protocol-Error packet in this way is unusual, it is both informative
and safe. and safe.
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
Server RADIUS version numbers have been given, and not the full ALPN strings
no ALPN | 1.0 | 1.0, 1.1 | 1.1 (e.g., "radius/1.0").
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
Figure 1: Possible outcomes for ALPN Negotiation
The table entries above have the following meaning:
Alert This table and the names given below are for informational and
descriptive purposes only.
The client sends ALPN, and the server does not agree to the +==========+======================================+
clients ALPN proposal. The server replies with a TLS alert of | Client | Server |
"no_application_protocol" (120), and then closes the TLS | +=========+=======+==========+=========+
connection. | | no ALPN | 1.0 | 1.0, 1.1 | 1.1 |
+==========+=========+=======+==========+=========+
| 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 |
+==========+---------+-------+----------+---------+
As the server replies with a TLS alert, the Protocol-Error Table 2: Possible Outcomes for ALPN
packet is not used here.
Close-C The table entries above have the following meaning:
The client sends ALPN, but the server does not respond with Alert
ALPN. The client closes the connection. The client sends ALPN, and the server does not agree to the
client's ALPN proposal. The server replies with a TLS alert of
"no_application_protocol" (120) and then closes the TLS
connection.
As noted in the previous section, the client MAY send a As the server replies with a TLS alert, the Protocol-Error packet
Protocol-Error packet to the server before closing the is not used here.
connection.
Close-S Close-C
The client sends ALPN, but the server does not respond with ALPN.
The client closes the connection.
The client does not send ALPN string(s), but the server As noted in the previous section, the client MAY send a Protocol-
requires ALPN. The server closes the connection. Error packet to the server before closing the connection.
As noted in the previous section, the server MAY send a Close-S
Protocol-Error packet to the client before closing the The client does not send ALPN string(s), but the server requires
connection. The server MAY also send a TLS alert of ALPN. The server closes the connection.
"no_application_protocol" (120) before closing the connection.
TLS As noted in the previous section, the server MAY send a Protocol-
Historic RADIUS/TLS is used. The client either sends no ALPN Error packet to the client before closing the connection. The
string, or sends "radius/1.0". The server either replies with server MAY also send a TLS alert of "no_application_protocol"
no ALPN string, or with "radius/1.0". The connection MUST use (120) before closing the connection.
historic RADIUS/TLS.
1.1 TLS
Historic RADIUS/TLS is used. The client either sends no ALPN
string or sends "radius/1.0". The server either replies with no
ALPN string or with "radius/1.0". The connection MUST use
historic RADIUS/TLS.
The client sends the ALPN string "radius/1.1. The server 1.1
acknowledges this negotiation with a reply of "radius/1.1", and The client sends the ALPN string "radius/1.1". The server
then RADIUS/1.1 is used. acknowledges this negotiation with a reply of "radius/1.1", and
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 which 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 on [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, that TLS alert in situations where it would be otherwise forbidden or
or perhaps unsupported. perhaps unsupported.
Finally, defining ALPN strings for all known RADIUS versions will Finally, defining ALPN strings for all known RADIUS versions will
make it easier to support additional ALPN strings if that make it easier to support additional ALPN strings if that
functionality is ever needed. functionality is ever needed.
3.5. Session Resumption 3.5. Session Resumption
[RFC7301], Section 3.1 states that ALPN is negotiated on each [RFC7301], Section 3.1 states that ALPN is negotiated on each
connection, even if session resumption is used: connection, even if session resumption is used:
When session resumption or session tickets [RFC5077] are used, the | When session resumption or session tickets [RFC5077] are used, the
previous contents of this extension are irrelevant, and only the | previous contents of this extension are irrelevant, and only the
values in the new handshake messages are considered. | values in the new handshake messages are considered.
In order to prevent down-bidding attacks, RADIUS systems which (Note: RFC 5077 was obsoleted by [RFC8446].)
In order to prevent down-bidding attacks, RADIUS systems that
negotiate the "radius/1.1" protocol MUST associate that information negotiate the "radius/1.1" protocol MUST associate that information
with the session ticket, and enforce the use of "radius/1.1" on 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 resumption. That is, if "radius/1.1" was negotiated for a
session, both clients and servers MUST behave as if the RADIUS/1.1 session, both clients and servers MUST behave as if the RADIUS/1.1
variable was set to "require" for that session. variable was set to "require" for that session.
A client which is resuming a "radius/1.1" connection MUST advertise A client that is resuming a "radius/1.1" connection MUST advertise
only the capability to do "radius/1.1" for the resumed session. That only the capability to do "radius/1.1" for the resumed session. That
is, even if the client configuration allows historic RADIUS/TLS for is, even if the client configuration allows historic RADIUS/TLS for
new connections, it MUST signal "radius/1.1" when resuming a session new connections, it MUST signal "radius/1.1" when resuming a session
which had previously negotiated "radius/1.1". that had previously negotiated "radius/1.1".
Similarly, when a server does resumption for a session which had Similarly, when a server does resumption for a session that had
previously negotiated "radius/1.1". If the client attempts to resume previously negotiated "radius/1.1", if the client attempts to resume
the sessions without signaling the use of RADIUS/1.1, the server MUST the sessions without signaling the use of RADIUS/1.1, the server MUST
close the connection. The server MUST send an appropriate TLS error, close the connection. The server MUST send an appropriate TLS error,
and also SHOULD log a descriptive message as described above. and also SHOULD log a descriptive message as described above.
In contrast, there is no requirement for a client or server to force In contrast, there is no requirement for a client or server to force
the use of [RFC6614] RADIUS/TLS on session resumption. Clients are the use of RADIUS/TLS from [RFC6614] on session resumption. Clients
free to signal support for "radius/1.1" on resumed sessions, even if are free to signal support for "radius/1.1" on resumed sessions, even
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 which is sent This section describes the application-layer data that is sent inside
inside of (D)TLS when using the RADIUS/1.1 protocol. Unless of (D)TLS when using the RADIUS/1.1 protocol. Unless otherwise
otherwise discussed herein, the application-layer data is unchanged discussed herein, the application-layer data is unchanged from
from traditional RADIUS. This protocol is only used when historic RADIUS. This protocol is only used when "radius/1.1" has
"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 meaning. The Identifier and the Request / 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 which 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
layer, RADIUS-specific cryptographic primitives are no longer needed layer, RADIUS-specific cryptographic primitives are no longer needed
or used in RADIUS/1.1. or used in RADIUS/1.1.
A summary of the RADIUS/1.1 packet format is shown below. The fields A summary of the RADIUS/1.1 packet format is shown below. The fields
are transmitted from left to right. are transmitted from left to right.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 18, line 22 skipping to change at line 812
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token | | Token |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Reserved-2 | | Reserved-2 |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ... | Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 2: The RADIUS/1.1 Packet Format Figure 1: The RADIUS/1.1 Packet Format
Code Code
The Code field is one octet and identifies the type of RADIUS
The Code field is one octet, and identifies the type of RADIUS
packet. packet.
The meaning of the Code field is unchanged from previous RADIUS The meaning of the Code field is unchanged from previous RADIUS
specifications. specifications.
Reserved-1 Reserved-1
The Reserved-1 field is one octet. The Reserved-1 field is one octet.
This field was previously used as the "Identifier" in historic This field was previously used as the "Identifier" in historic
RADIUS/TLS. It is now unused, as the Token field replaces it both RADIUS/TLS. It is now unused, as the Token field replaces it both
as the way to identify requests, and to associate responses with as the way to identify requests and to associate responses with
requests. requests.
When sending packets, the Reserved-1 field MUST be set to zero. When sending packets, the Reserved-1 field MUST be set to zero.
The Reserved-1 field MUST be ignored when receiving a packet. The Reserved-1 field MUST be ignored when receiving a packet.
Length Length
The Length field is two octets. The Length field is two octets.
The meaning of the Length field is unchanged from previous RADIUS The meaning of the Length field is unchanged from previous RADIUS
specifications. specifications.
Token Token
The Token field is four octets, and aids in matching requests and The Token field is four octets and aids in matching requests and
replies, as a replacement for the Identifier field. The RADIUS replies, as a replacement for the Identifier field. The RADIUS
server can detect a duplicate request if it receives the same server can detect a duplicate request if it receives the same
Token value for two packets on a particular connection. Token value for two packets on a particular connection.
All values are possible for the Token field. Implementations MUST All values are possible for the Token field. Implementations MUST
treat the Token as an opaque blob when comparing Token values. treat the Token as an opaque blob when comparing Token values.
Further requirements are given below in Section 4.2.1 for sending Further requirements are given below in Section 4.2.1 for sending
packets, and in Section 4.2.2 for receiving packets. packets and in Section 4.2.2 for receiving packets.
Reserved-2 Reserved-2
The Reserved-2 field is twelve (12) octets in length. 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 set to zero when sending a packet.
These octets MUST be ignored when receiving a packet. These octets MUST be ignored when receiving a packet.
These octets are reserved for future protocol extensions. These octets are reserved for future protocol extensions.
4.2. The Token Field 4.2. The Token Field
This section describes in more detail how the Token field is used. This section describes in more detail how the Token field is used.
4.2.1. Sending Packets 4.2.1. Sending Packets
The Token field MUST change for every new unique packet which is sent The Token field MUST change for every new unique packet that is sent
on the same connection. For DTLS transport, it is possible to on the same connection. For DTLS transport, it is possible to
retransmit duplicate packets, in which case the Token value MUST NOT retransmit duplicate packets, in which case the Token value MUST NOT
be changed when a duplicate packet is (re)sent. When the contents of be changed when a duplicate packet is (re)sent. When the contents of
a retransmitted packet change for any reason (such changing Acct- a retransmitted packet change for any reason (such as changing Acct-
Delay-Time as discussed in [RFC2866], Section 5.2), the Token value Delay-Time as discussed in [RFC2866], Section 5.2), the Token value
MUST be changed. Note that on reliable transports, packets are never MUST be changed. Note that on reliable transports, packets are never
retransmitted, and therefore every new packet which is sent has a retransmitted; therefore, every new packet that is sent has a unique
unique Token value. Token value.
We note that in previous RADIUS specifications, the Identifier field We note that in previous RADIUS specifications, the Identifier field
could have the same value for different packets on the same could have the same value for different packets on the same
connection. For example, Access-Request (Code 1) and Accounting- connection. For example, Access-Request (Code 1) and Accounting-
Request (Code 4) packets could both use ID 3, and still be treated as Request (Code 4) packets could both use ID 3 and still be treated as
different packets. This overlap required that RADIUS clients and different packets. This overlap requires that RADIUS clients and
servers track the Identifier field, not only on a per-connection servers track the Identifier field, not only on a per-connection
basis, but also on a per-Code basis. This behavior adds complexity basis, but also on a per-Code basis. This behavior adds complexity
to implementations. to implementations.
In contrast, the Token values MUST be generated from a 32-bit counter In contrast, the Token values MUST be generated from a 32-bit counter
which is unique to each connection. Such a counter SHOULD be that is unique to each connection. Such a counter SHOULD be
initialized to a random value, taken from a random number generator, initialized to a random value, taken from a random number generator,
whenever a new connection is opened. The counter MUST then be whenever a new connection is opened. The counter MUST then be
incremented for every unique new packet which is sent by the client. incremented for every unique new packet that is sent by the client.
Retransmissions of the same packet MUST use the same unchanged Token Retransmissions of the same packet MUST use the same unchanged Token
value. As the Token value is mandated to be unique per packet, a value. As the Token value is mandated to be unique per packet, a
duplicate Token value is the only way that a server can detect duplicate Token value is the only way that a server can detect
duplicate transmissions. duplicate transmissions.
This counter method ensures that the Tokens are unique, and are also This counter method ensures that the Tokens are unique and are also
independent of any Code value in the RADIUS packet header. This independent of any Code value in the RADIUS packet header. This
method is mandated because any other method of generating unique and method is mandated because any other method of generating unique and
non-conflicting Token values is more complex, with no additional non-conflicting Token values is more complex, with no additional
benefit and only the likelihood of increased bugs and benefit and only the likelihood of increased bugs and
interoperability issues. Any other method for generating Token interoperability issues. Any other method for generating Token
values would require substantially more resources to track values would require substantially more resources to track
outstanding Token values and their associated expiry times. The outstanding Token values and their associated expiry times. The
chance that initial values could potentially cause any confusion by chance that initial values could potentially cause any confusion by
being re-used across two connections is one in 2^32, which is being reused across two connections is one in 2^32, which is
acceptable. acceptable.
The purpose for initializing the Token to a random counter is mainly The purpose for initializing the Token to a random counter is mainly
to aid administrators in debugging systems. If the Token values to aid administrators in debugging systems. If the Token values
always used the same sequence, then it would easier for a person to always used the same sequence, then it would easier for a person to
confuse different packets which have the same Token value. By confuse different packets that have the same Token value. By instead
instead starting with a random value, those values are more evenly starting with a random value, those values are more evenly
distributed across the set of allowed values, and are therefore more distributed across the set of allowed values; therefore, they are
likely to be unique. more likely to be unique.
As there is no special meaning for the Token, there is no meaning As there is no special meaning for the Token, there is no meaning
when a counter "wraps" around from a high value back to zero. The when a counter "wraps" around from a high value back to zero. The
originating system can simply continue to increment the Token value originating system can simply continue to increment the Token value
without taking any special action in that situation. without taking any special action in that situation.
Once a RADIUS response to a request has been received and there is no Once a RADIUS response to a request has been received and there is no
need to track the packet any longer, the Token value can be reused. need to track the packet any longer, the Token value can be reused.
This reuse happens only when the counter "wraps around" after 2^32 This reuse happens only when the counter "wraps around" after 2^32
packets have been sent over one connection. This method of managing packets have been sent over one connection. This method of managing
the counter automatically ensures a long delay (i.e. 2^32 packets) the counter automatically ensures a long delay (i.e., 2^32 packets)
between multiple uses of the same Token value. This large number of between multiple uses of the same Token value. This large number of
packets ensures that the only possible situation where there may be packets ensures that the only possible situation where there may be
conflict is when a client sends billions of packets a second across conflict is when a client sends billions of packets a second across
one connection, or when a client sends billions of packets without one connection, or when a client sends billions of packets without
receiving replies. We suggest that such situations are vanishingly receiving replies. We suggest that such situations are vanishingly
rare. The best solution to those situations would be to limit the rare. The best solution to those situations would be to limit the
number out outstanding packets over one connection to a number much number of outstanding packets over one connection to a number much
lower than billions. lower than billions.
If a RADIUS client has multiple independent subsystems which send If a RADIUS client has multiple independent subsystems that send
packets to a server, each subsystem MAY open a new connection which packets to a server, each subsystem MAY open a new connection that is
is unique to that subsystem. There is no requirement that all unique to that subsystem. There is no requirement that all packets
packets go over one particular connection. That is, despite the use go over one particular connection. That is, despite the use of a
of a 32-bit Token field, RADIUS/1.1 clients are still permitted to 32-bit Token field, RADIUS/1.1 clients are still permitted to open
open multiple source ports as discussed in [RFC2865] Section 2.5. multiple source ports as discussed in [RFC2865], Section 2.5.
While multiple connections from client to server are allowed, We While multiple connections from client to server are allowed, we
reiterate the suggestion of [RFC3539], Section 3.3 that a single reiterate the suggestion of [RFC3539], Section 3.3 that a single
connection is preferred to multiple connections. The use of a single connection is preferred to multiple connections. The use of a single
connection can improve throughput and latency, while simplifying the connection can improve throughput and latency, while simplifying the
clients efforts to determine server status. client's efforts to determine server status.
4.2.2. Receiving Packets 4.2.2. Receiving Packets
A server which receives RADIUS/1.1 packets MUST perform packet A server that receives RADIUS/1.1 packets MUST perform packet
deduplication for all situations where it is required by RADIUS. deduplication for all situations where it is required by RADIUS.
Where RADIUS does not require deduplication (e.g. TLS transport), Where RADIUS does not require deduplication (e.g., TLS transport),
the server SHOULD NOT do deduplication. However, DTLS transport is the server SHOULD NOT do deduplication. However, DTLS transport is
UDP-based, and therefore still requires deduplication. UDP-based, and therefore still requires deduplication.
When using RADIUS/1.1, implementations MUST do deduplication only on When using RADIUS/1.1, implementations MUST do deduplication only on
the Token field, and not on any other field or fields in the packet the Token field, and not on any other field or fields in the packet
header. A server MUST treat the Token as being an opaque field with header. A server MUST treat the Token as being an opaque field with
no intrinsic meaning. This requirement makes the receiver behavior no intrinsic meaning. This requirement makes the receiver behavior
independent of the methods by which the Counter is generated. independent of the methods by which the Counter is generated.
Where Token deduplication is done, it MUST be done on a per- Where Token deduplication is done, it MUST be done on a per-
connection basis. If two packets which are received on different connection basis. If two packets that are received on different
connections contain the same Token value, then those packets MUST be connections contain the same Token value, then those packets MUST be
treated as distinct (i.e. different) packets. Systems performing treated as distinct (i.e., different) packets. Systems performing
deduplication MAY still track the packet Code, Length, and Attributes deduplication MAY still track the packet Code, Length, and Attributes
which is associated with a Token value. If it determines that the that are associated with a Token value. If it determines that the
sender is re-using Token values for distinct outstanding packets, sender is reusing Token values for distinct outstanding packets, then
then an error should be logged, and the connection MUST be closed. an error should be logged, and the connection MUST be closed. There
There is no way to negotiate correct behavior in the protocol. is no way to negotiate correct behavior in the protocol. Either both
Either the parties both operate normally and can communicate, or one parties operate normally and can communicate, or one end misbehaves
end misbehaves, and no communication is possible. and no communication is possible.
Once a reply has been sent, a system doing deduplication SHOULD cache Once a reply has been sent, a system doing deduplication SHOULD cache
the replies as discussed in [RFC5080], Section 2.2.2: the replies as discussed in [RFC5080], Section 2.2.2:
Each cache entry SHOULD be purged after a period of time. This | Each cache entry SHOULD be purged after a period of time. This
time SHOULD be no less than 5 seconds, and no more than 30 | time SHOULD be no less than 5 seconds, and no more than 30
seconds. After about 30 seconds, most RADIUS clients and end | seconds. After about 30 seconds, most RADIUS clients and end
users will have given up on the authentication request. | users will have given up on the authentication request.
Therefore, there is little value in having a larger cache timeout. | Therefore, there is little value in having a larger cache timeout.
This change from RADIUS means that the Identifier field is no longer This change from RADIUS means that the Identifier field is no longer
useful for RADIUS/1.1. The Reserved-1 field (previously used as the useful for RADIUS/1.1. The Reserved-1 field (previously used as the
Identifier) MUST be set to zero when encoding all RADIUS/1.1 packets. Identifier) MUST be set to zero when encoding all RADIUS/1.1 packets.
Implementations of RADIUS/1.1 which receive packets MUST ignore this Implementations of RADIUS/1.1 that receive packets MUST ignore this
field. field.
5. Attribute handling 5. Attribute Handling
Most attributes in RADIUS have no special encoding "on the wire", or Most attributes in RADIUS have no special encoding "on the wire", or
any special meaning between client and server. Unless discussed in any special meaning between client and server. Unless discussed in
this section, all RADIUS attributes are unchanged in this this section, all RADIUS attributes are unchanged in this
specification. This requirement includes attributes which contain a specification. This requirement includes attributes that contain a
tag, as defined in [RFC2868]. tag, as defined in [RFC2868].
5.1. Obfuscated Attributes 5.1. Obfuscated Attributes
Since the (D)TLS layer provides for connection authentication, Since the (D)TLS layer provides for connection authentication,
integrity checks, and confidentiality, there is no need to hide the 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 contents of an attribute on a hop-by-hop basis. As a result, all
attributes defined as being obfuscated via the shared secret no attributes defined as being obfuscated via the shared secret no
longer have the obfuscation step applied when RADIUS/1.1 is used. longer have the obfuscation step applied when RADIUS/1.1 is used.
Instead, those attributes MUST be encoded using the encoding for the Instead, those attributes MUST be encoded using the encoding for the
underlying data type, with any encryption / obfuscation step omitted. underlying data type, with any encryption / obfuscation step omitted.
For example, the User-Password attribute is no longer obfuscated, and For example, the User-Password attribute is no longer obfuscated and
is instead sent as data type "text". is instead sent as data type "text".
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 which 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 others 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 [RFC6614], Section 2.4 item (3) and follow the requirements of item (3) from [RFC6614], Section 3.4 and
[RFC7360], Section 10.4, which mandates that RADIUS over TLS also follow [RFC7360], Section 10.4, which mandates that RADIUS over
implementations validate the peer before sending any RADIUS traffic. TLS implementations validate the peer before sending any RADIUS
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 which never sends authenticated to use an authentication protocol that never sends
passwords (e.g. EAP-pwd [RFC5931]), or which 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 configuring an authentication protocol are strongly TLS tunnel (e.g., EAP Tunneled Transport Layer Security (EAP-TTLS)
site-dependent, so further discussion of these issues are outside of [RFC5281]). The processes to choose and configure an authentication
the scope of this document. The goal here is to ensure that the protocol are strongly site dependent, so further discussions of these
reader 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.
Clients which send CHAP-Password attribute ([RFC2865], Section 5.3) Clients that send a CHAP-Password attribute ([RFC2865], Section 5.3)
in an Access-Request packet over a RADIUS/1.1 connection MUST also in an Access-Request packet over a RADIUS/1.1 connection MUST also
include a CHAP-Challenge attribute ([RFC2865], Section 5.40). include a CHAP-Challenge attribute ([RFC2865], Section 5.40).
Proxies may need to receive Access-Request packets over a non- Proxies may need to receive Access-Request packets over a non-
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' which 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, and 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' printable text or UTF-8 data as per the definition of the "text" data
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 which 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 connection, the attribute MUST be silently discarded or treated as an
an "invalid attribute", as defined in [RFC6929], Section 2.8. That "invalid attribute", as defined in [RFC6929], Section 2.8. That is,
is, the Message-Authenticator attribute is no longer used to the Message-Authenticator attribute is no longer used to authenticate
authenticate packets for the RADIUS/1.1 transport. Its existence (or packets for the RADIUS/1.1 transport. Its existence (or not) in this
not) in this transport is meaningless. transport is meaningless.
A system which receives a Message-Authenticator attribute in a packet A system that receives a Message-Authenticator attribute in a packet
MUST treat it as an "invalid attribute" as defined in [RFC6929], 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 Section 2.8. That is, the packet can still be processed, even if the
Message-Authenticator attribute is ignored. Message-Authenticator attribute is ignored.
For proxies, the Message-Authenticator attribute has always been For proxies, the Message-Authenticator attribute has always been
defined as being created and consumed on a "hop by hop" basis. That defined as being created and consumed on a "hop-by-hop" basis. That
is, a proxy which received a Message-Authenticator attribute from a is, a proxy that received a Message-Authenticator attribute from a
client would never forward that attribute as-is to another server. client would never forward that attribute as is to another server.
Instead, the proxy would either suppress, or re-create, the Message- Instead, the proxy would either suppress or recreate the Message-
Authenticator attribute in the outgoing request. This existing Authenticator attribute in the outgoing request. This existing
behavior is leveraged in RADIUS/1.1 to suppress the use of Message- behavior is leveraged in RADIUS/1.1 to suppress the use of the
Authenticator over a RADIUS/1.1 connection. Message-Authenticator over a RADIUS/1.1 connection.
A proxy may receive an Access-Request packet over a RADIUS/1.1 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 connection and then forward that packet over a RADIUS/UDP or a
RADIUS/TCP connection. In that situation, the proxy SHOULD add a RADIUS/TCP connection. In that situation, the proxy SHOULD add a
Message-Authenticator attribute to every Access-Request packet which Message-Authenticator attribute to every Access-Request packet that
is sent over an insecure transport protocol. is sent over an insecure transport protocol.
The original text in [RFC3579], Section 3.3, "Note 1" paragraph The original text in [RFC3579], Section 3.3, Note 1 required that the
required that the Message-Authenticator attribute be present for Message-Authenticator attribute be present for certain Access-Request
certain Access-Request packets. It also required the use of Message- packets. It also required the use of the Message-Authenticator when
Authenticator when the Access-Request packet contained an EAP-Message the Access-Request packet contained an EAP-Message attribute.
attribute. Experience has shown that some RADIUS clients never use Experience has shown that some RADIUS clients never use the Message-
the Message-Authenticator, even for the situations where its use is Authenticator, even for the situations where its use is suggested.
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 Message-Authenticator in Access-Request packets when include Message-Authenticator in Access-Request packets when using
using UDP or TCP transport. As the scope of this document is limited UDP or TCP transport. As the scope of this document is limited to
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.
Further issues related to Message-Authenticator are discussed in
[DEPRECATE-RADIUS].
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 "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 "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, 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 PEAP or TTLS. authentication methods as with the Protected Extensible
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 which 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
generated the protocol error so that clients can disambiguate | generated the protocol error so that clients can disambiguate
requests with different codes and the same ID. | requests with different codes and the same ID.
This attribute is no longer needed in RADIUS/1.1. The Identifier 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" field is unused, so it impossible for two requests to have the "same"
ID. Instead, the Token field permits clients and servers to ID. Instead, the Token field permits clients and servers to
correlate requests and responses, independent of the Code value being correlate requests and responses, independent of the Code value being
used. used.
Therefore, the Original-Packet-Code attribute ([RFC7930], Section 4) Therefore, the Original-Packet-Code attribute ([RFC7930], Section 4)
MUST NOT be sent over a RADIUS/1.1 connection. If it is received in 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 a packet, it MUST be treated as an "invalid attribute" as defined in
[RFC6929], Section 2.8. [RFC6929], Section 2.8.
6. Other Considerations when using ALPN 6. Other Considerations When Using ALPN
Most of the differences between RADIUS and RADIUS/1.1 are in the Most of the differences between RADIUS and RADIUS/1.1 are in the
packet header and attribute handling, as discussed above. The packet header and attribute handling, as discussed above. The
remaining issues are a small set of unrelated topics, and are remaining issues are a small set of unrelated topics, and are
discussed here. discussed here.
6.1. Protocol-Error 6.1. Protocol-Error
There are a number of situations where a RADIUS server is unable to 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 respond to a request. One situation is where the server depends on a
database, and the database is down. While arguably the server should database, and the database is down. While arguably the server should
close all incoming connections when it is unable to do anything, this close all incoming connections when it is unable to do anything, this
action is not always effective. A client may aggressively try to action is not always effective. A client may aggressively try to
open new connections, or send packets to an unconnected UDP open new connections or send packets to an unconnected UDP
destination where the server is not listening. Another situation destination where the server is not listening. Another situation
where the server is unable to respond is when the server is proxying where the server is unable to respond is when the server is proxying
packets, and the outbound connections are either full or failed. packets, and the outbound connections are either full or failed.
In all RADIUS spercifications prior to this one, there is no way for In all RADIUS specifications prior to this one, there is no way for
the server to send a client the positive signal that it received a the server to send a client the positive signal that it received a
request, but is unable to send a response. Instead, the server request but is unable to send a response. Instead, the server
usually just discards the request, which to the client is usually just discards the request, which to the client is
indistinguishable from the situation where the server is down. This indistinguishable from the situation where the server is down. This
failure case is made worse by the fact that perhaps some proxied failure case is made worse by the fact that perhaps some proxied
packets succeed while others fail. The client can only conclude then packets succeed while others fail. The client can only conclude then
that the server is randomly dropping packets, and is unreliable. that the server is randomly dropping packets and is unreliable.
It would be very useful for servers to signal to clients that they It would be very useful for servers to signal to clients that they
have received a request, but are unable to process it. This have received a request but are unable to process it. This
specification uses the Protocol-Error packet [RFC7930], Section 4 as specification uses the Protocol-Error packet ([RFC7930], Section 4)
that signal. The use of Protocol-Error allows for both hop-by-hop 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- signaling in the case of proxy forwarding errors, and also for end-
to-end signaling of server to client. Such signaling should greatly to-end signaling of server to client. Such signaling should greatly
improve the robustness of the RADIUS protocol. improve the robustness of the RADIUS protocol.
When a RADIUS/1.1 server determines that it is unable to process an 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 Access-Request or Accounting-Request packet, it MUST respond with a
Protocol-Error packet containing an Error-Cause attribute. A proxy Protocol-Error packet containing an Error-Cause attribute. A proxy
which cannot forward the packet MUST respond with either 502 (Request that cannot forward the packet MUST respond with either 502 (Request
Not Routable (Proxy)), or 505 (Other Proxy Processing Error). This Not Routable (Proxy)) or 505 (Other Proxy Processing Error). This
requirement is to help distinguish failures in the proxy chain from requirement is to help distinguish failures in the proxy chain from
failures at the final (i.e. home) server, failures at the final (i.e., home) server.
For a home server, if none of the Error-Cause values match the reason 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 for the failure, then the value 506 (Resources Unavailable) MUST be
used. used.
When a RADIUS proxy receives a Protocol-Error reply, it MUST examine 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 the value of the Error-Cause attribute. If there is no Error-Cause
attribute, or its value is something other than 502 (Request Not attribute, or if its value is something other than 502 (Request Not
Routable (Proxy)), 505 (Other Proxy Processing Error), or 506 Routable (Proxy)), 505 (Other Proxy Processing Error), or 506
(Resources Unavailable), the proxy MUST return the Protocol-Error (Resources Unavailable), then the proxy MUST return the Protocol-
response packet to the client, and include the Error-Cause attribute Error response packet to the client and include the Error-Cause
from the response it received. This process allows for full "end to attribute from the response it received. This process allows for
end" signaling of servers to clients. full "end-to-end" signaling of servers to clients.
In all situations other then outlined in the preceding paragraph, a In all situations other than those outlined in the preceding
client which receives a Protocol-Error reply MUST re-process the paragraph, a client that receives a Protocol-Error reply MUST
original outgoing packet through the client forwarding algorithm. reprocess the original outgoing packet through the client forwarding
This requirement includes both clients which originate RADIUS algorithm. This requirement includes both clients that originate
traffic, and proxies which see an Error-Cause attribute of 502 RADIUS traffic and proxies that see an Error-Cause attribute of 502
(Request Not Routable (Proxy)), or 505 (Other Proxy Processing (Request Not Routable (Proxy)) or 505 (Other Proxy Processing Error).
Error).
The expected result of this processing is that the client forwards The expected result of this processing is that the client forwards
the packet to a different server. Clients MUST NOT forward the the packet to a different server. Clients MUST NOT forward the
packet over the same connection, and SHOULD NOT forward it to over a packet over the same connection and SHOULD NOT forward it over a
different connection to the same server. different connection to the same server.
This process may continue over multiple connections and multiple This process may continue over multiple connections and multiple
servers, until the client either times out the request, or fails to servers, until the client either times out the request or fails to
find a forwarding destination for the packet. A proxy which is find a forwarding destination for the packet. A proxy that is unable
unable to forward a packet MUST reply with a Protocol-Error packet to forward a packet MUST reply with a Protocol-Error packet
containing Error-Cause, as defined above. A client which originates containing an Error-Cause, as defined above. A client that
packets MUST treat such a request as if it had received no response. 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 This behavior is intended to improve the stability of the RADIUS
protocol by addressing issues first raised in [RFC3539], Section 2.8. protocol by addressing issues first raised in [RFC3539], Section 2.8.
6.2. Status-Server 6.2. Status-Server
[RFC6613], Section 2.6.5, and by extension [RFC7360], suggest that [RFC6613], Section 2.6.5, and by extension [RFC7360], suggest that
the Identifier value zero (0) be reserved for use with Status-Server the Identifier value zero (0) be reserved for use with Status-Server
as an application-layer watchdog. This practice MUST NOT be used for 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 RADIUS/1.1, as the Identifier field is not used in this transport
profile. profile.
The rationale for reserving one value of the Identifier field was the The rationale for reserving one value of the Identifier field was the
limited number of Identifiers available (256), and the overlap in limited number of Identifiers available (256) and the overlap in
Identifiers between Access-Request packets and Status-Server packets. Identifiers between Access-Request packets and Status-Server packets.
If all 256 Identifier values had been used to send Access-Request If all 256 Identifier values had been used to send Access-Request
packets, then there would be no Identifier value available for packets, then there would be no Identifier value available for
sending a Status-Server packet. sending a Status-Server packet.
In contrast, the Token field allows for 2^32 outstanding packets on 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- 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 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 the Token field. If instead there are 2^32 outstanding packets
for one connection, then it is likely that something has gone for one connection, then it is likely that something has gone
catastrophically wrong. In that case, the safest way forward is catastrophically wrong. In that case, the safest way forward is
likely to just close the connection. likely to just close the connection.
6.3. Proxies 6.3. Proxies
A RADIUS proxy normally decodes and then re-encodes all attributes, A RADIUS proxy normally decodes and then re-encodes all attributes,
included obfuscated ones. A RADIUS proxy will not generally rewrite including obfuscated ones. A RADIUS proxy will not generally rewrite
the content of the attributes it proxies (unless site-local policy the content of the attributes it proxies (unless site-local policy
requires such a rewrite). While some attributes may be modified due requires such a rewrite). While some attributes may be modified due
to administrative or policy rules on the proxy, the proxy will to administrative or policy rules on the proxy, the proxy will
generally not rewrite the contents of attributes such as User- generally not rewrite the contents of attributes such as User-
Password, Tunnel-Password, CHAP-Password, MS-CHAP-Password, MS-MPPE Password, Tunnel-Password, CHAP-Password, MS-CHAP-Password, MS-MPPE
keys, etc. All attributes are therefore transported through a keys, etc. Therefore, all attributes are transported through a
RADIUS/1.1 connection without changing their values or contents. RADIUS/1.1 connection without changing their values or contents.
A proxy may negotiate RADIUS/1.1 (or not) with a particular client or 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 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 servers it connects to, in any combination. As a result, this
specification is fully compatible with all past, present, and future specification is fully compatible with all past, present, and future
RADIUS attributes. RADIUS attributes.
7. Other RADIUS Considerations 7. Other RADIUS Considerations
This section discusses issues in RADIUS which need to be addressed in This section discusses issues in RADIUS that need to be addressed in
order to support ALPN, but which aren't direcly part of the order to support ALPN, but which aren't directly part of the
RADIUS/1.1 protocol. RADIUS/1.1 protocol.
7.1. Crypto-Agility 7.1. Crypto-Agility
The crypto-agility requirements of [RFC6421] are addressed in The crypto-agility requirements of [RFC6421] are addressed in
[RFC6614], Appendix C, and in [RFC7360], Section 10.1. This [RFC6614], Appendix C and in [RFC7360], Section 10.1. This
specification makes no changes from, or additions to, those specification makes no changes or additions to those specifications.
specifications. The use of ALPN, and the removal of MD5 has no The use of ALPN and the removal of MD5 has no impact on the security
impact on security or privacy of the protocol. or privacy of the protocol.
RADIUS/TLS has been widely deployed in at least eduroam [RFC7593] and RADIUS/TLS has been widely deployed in at least eduroam ([RFC7593]
[EDUROAM] and in OpenRoaming [OPENROAMING]. RADIUS/DTLS has seen and [EDUROAM]) and in OpenRoaming [OPENROAMING]. RADIUS/DTLS has
less adoption, but it is known to be supported in many RADIUS clients seen less adoption, but it is known to be supported in many RADIUS
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 page 31, line 10 skipping to change at line 1404
appear in Access-Reject packets. No explanation is given for this appear in Access-Reject packets. No explanation is given for this
change from [RFC5176]. There is not even an acknowledgment that this change from [RFC5176]. There is not even an acknowledgment that this
suggestion is a change from any previous specification. We correct suggestion is a change from any previous specification. We correct
that issue here. that issue here.
This specification updates [RFC5176] to allow the Error-Cause This specification updates [RFC5176] to allow the Error-Cause
attribute to appear in Access-Reject packets. It is RECOMMENDED that attribute to appear in Access-Reject packets. It is RECOMMENDED that
implementations include the Error-Cause attribute in Access-Reject implementations include the Error-Cause attribute in Access-Reject
packets where appropriate. packets where appropriate.
That is, the reason for sending the Access-Reject packet (or That is, the reason for sending the Access-Reject packet (or the
Protocol-Error packet) may match a defined Error-Cause value. In Protocol-Error packet) may match a defined Error-Cause value. In
that case, it is useful for implementations to send an Error-Cause that case, it is useful for implementations to send an Error-Cause
attribute with that value. This behavior can help RADIUS system attribute with that value. This behavior can help RADIUS system
administrators debug issues in complex proxy chains. administrators debug issues in complex proxy chains.
For example, a proxy may normally forward Access-Request packets For example, a proxy may normally forward Access-Request packets that
which contain EAP-Message attributes. The proxy can determine if the contain EAP-Message attributes. The proxy can determine if the
contents of the EAP-Message are invalid. On example of an invalid contents of the EAP-Message are invalid. One example of an invalid
EAP-Message is where the first octet has value larger than 4. In EAP-Message is where the first octet has value larger than 4. In
that case, there may be no benefit to forwarding the packet, as the 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 home server will reject it. It may then be possible for the proxy
(with the knowledge and consent of involved parties) to immediately (with the knowledge and consent of involved parties) to immediately
reply with an Access-Reject containing an Error-Cause attribute with reply with an Access-Reject containing an Error-Cause attribute with
value 202 for "Invalid EAP Packet (Ignored)". value 202 (Invalid EAP Packet (Ignored)).
Another possibility is that if a proxy is configured to forward Another possibility is that a proxy is configured to forward packets
packets for a particular realm, but it has determined that there are for a particular realm, but it has determined that there are no
no available connections to the next hop for that realm. In that available connections to the next hop for that realm. In that case,
case, it may be possible for the proxy (again with the knowledge and it may be possible for the proxy (again, with the knowledge and
consent of involved parties) to reply with an Access-Reject consent of involved parties) to reply with an Access-Reject
containing an Error-Cause attribute with value 502 for "Request Not containing an Error-Cause attribute with value 502 (Request Not
Routable (Proxy)" Routable (Proxy)).
These examples are given only for illustrative and informational These examples are given only for illustrative and informational
purposes. While it is useful to return an informative value for the purposes. While it is useful to return an informative value for the
Error-Cause attribute, proxies can only modify the traffic they Error-Cause attribute, proxies can only modify the traffic they
forward with the explicit knowledge and consent of all involved forward with the explicit knowledge and consent of all involved
parties. parties.
7.3. Future Standards 7.3. Future Standards
Future work may define new attributes, packet types, etc. It is Future work may define new attributes, packet types, etc. It is
important to be able to do such work without requiring that every new important to be able to do such work without requiring that every new
standard mention RADIUS/1.1 explicitly. This document defines standard mention RADIUS/1.1 explicitly. This document defines
RADIUS/1.1 as having functional overlap with legacy RADIUS: the RADIUS/1.1 as having functional overlap with legacy RADIUS: the
protocol state machine is unchanged, the packet header Code field is protocol state machine is unchanged, the packet header Code field is
unchanged, and the attribute format is largely unchanged. As a unchanged, and the attribute format is largely unchanged. As a
result, any new packet Code or attribute defined for RADIUS is result, any new packet Code or attribute defined for RADIUS is
explicitly compatible with RADIUS/1.1: the field contents and explicitly compatible with RADIUS/1.1; the field contents and
meanings are identical. The only difference between the two meanings are identical. The only difference between the two
protocols is that obfuscated attributes in RADIUS are not obfuscated protocols is that obfuscated attributes in RADIUS are not obfuscated
in RADIUS/1.1, and this document defines how that mapping is done. in RADIUS/1.1, and this document defines how that mapping is done.
Any future specification needs to mention RADIUS/1.1 only if it adds Any future specification only needs to mention RADIUS/1.1 if it adds
fields to the RADIUS/1.1 packet header. Otherwise, transport fields to the RADIUS/1.1 packet header. Otherwise, transport
considerations for RADIUS/1.1 are identical to RADIUS over (D)TLS. considerations for RADIUS/1.1 are identical to RADIUS over (D)TLS.
We reiterate that this specification defines a new transport profile We reiterate that this specification defines a new transport profile
for RADIUS. It does not define a completely new protocol. Any for RADIUS. It does not define a completely new protocol. Any
future specification which defines a new attribute MUST define it for future specification that defines a new attribute MUST define it for
RADIUS/UDP first, after which those definitions can be applied to RADIUS/UDP first, and afterwards those definitions can be applied to
this transport profile. this transport profile.
New specifications MAY define new attributes which use the New specifications MAY define new attributes that use the obfuscation
obfuscation methods for User-Password as defined in [RFC2865], methods for User-Password as defined in [RFC2865], Section 5.2 or for
Section 5.2, or for Tunnel-Password as defined in [RFC2868], Tunnel-Password as defined in [RFC2868], Section 3.5. There is no
Section 3.5. There is no need for those specifications to describe need for those specifications to describe how those new attributes
how those new attributes are transported in RADIUS/1.1. Since are transported in RADIUS/1.1. Since RADIUS/1.1 does not use MD5,
RADIUS/1.1 does not use MD5, any obfuscated attributes will by any obfuscated attributes will by definition be transported as their
definition be transported as their underlying data type, "text" underlying data type "text" ([RFC8044], Section 3.4) or "string"
([RFC8044], Section 3.4) or "string" ([RFC8044], Section 3.5). ([RFC8044], Section 3.5).
New RADIUS specifications MUST NOT define attributes which can only New RADIUS specifications MUST NOT define attributes that can only be
be transported via RADIUS over TLS. The RADIUS protocol has no way transported via RADIUS over TLS. The RADIUS protocol has no way to
to signal the security requirements of individual attributes. Any signal the security requirements of individual attributes. Any
existing implementation will handle these new attributes as "invalid existing implementation will handle these new attributes as "invalid
attributes" ([RFC6929], Section 2.8), and could forward them over an attributes" ([RFC6929], Section 2.8) and could forward them over an
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 which are only therefore inappropriate to define new attributes that are only secure
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 transport profile or make any special provisions for dealing with it.
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. Implementation Status 8. Privacy Considerations
(This section to be removed by the RFC editor.)
This specification is being implemented (client and server) in the
FreeRADIUS project which is hosted on GitHub at
https://github.com/FreeRADIUS/freeradius-server/tree/v3.2.x The code
implementation "diff" is approximately 1,000 lines, including build
system changes and changes to configuration parsers.
9. 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].
10. 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 When an implementation receives the packets for a RADIUS version that
which is not supported by this connection, it will not be able to is not supported by this connection, it will not be able to process
process the packets. Implementations can produce log messages the packets. Implementations can produce log messages indicating
indicating that the application-layer data is unexpected, and close that the application-layer data is unexpected and close the
the connection. In addition, the implementations which see the connection. In addition, the implementations that see the incorrect
incorrect application data already have full access to all secrets, application data already have full access to all secrets, passwords,
passwords, etc. being transported, so any protocol differences do not etc. being transported, so any protocol differences do not result in
result any security issue. Since all of the application data is any security issues. Since all of the application data is protected
protected by TLS, there is no possibility for an attacker to obtain by TLS, there is no possibility for an attacker to obtain any extra
any extra data as a result of this misconfiguration. data as a result of this misconfiguration.
RADIUS/1.0 requests sent over a RADIUS/1.1 connection may be accepted RADIUS/1.0 requests sent over a RADIUS/1.1 connection may be accepted
by the RADIUS/1.1 server, as the server will ignore the ID field, and by the RADIUS/1.1 server, as the server will ignore the ID field and
try to use portions of the Request Authenticator as a Token. try to use portions of the Request Authenticator as a Token.
However, the reply from the RADIUS/1.1 server will fail the Response However, the reply from the RADIUS/1.1 server will fail the Response
Authenticator validation by the RADIUS/1.0 client. The responses Authenticator validation by the RADIUS/1.0 client. Therefore, the
will therefore be dropped. The client will generally log these responses will be dropped. The client will generally log these
failures, and an administrator will address the issue. failures, and an administrator will address the issue.
RADIUS/1.1 requests sent over a RADIUS/1.0 connection will generally RADIUS/1.1 requests sent over a RADIUS/1.0 connection will generally
be discarded the the RADIUS/1.0 server, as the packets will fail the be discarded by the RADIUS/1.0 server, as the packets will fail the
Request Authenticator checks. That is, all request packets such as Request Authenticator checks. That is, all request packets such as
Accounting-Request, CoA-Request, and Disconnect-Request will be Accounting-Request, CoA-Request, and Disconnect-Request will be
discarded by the server. For Access-Request packets containing EAP- discarded by the server. For Access-Request packets containing EAP-
Message, the packets will be missing Message-Authenticator, and will Message, the packets will be missing Message-Authenticator and will
therefore be discarded by the server. Other Access-Request packets therefore be discarded by the server. Other Access-Request packets
contain obfuscated attributes such as User-Password will have those that contain obfuscated attributes such as User-Password will have
attributes decoded to nonsense, and will thus result in Access-Reject those attributes decoded to nonsense, thus resulting in Access-Reject
responses. responses.
RADIUS/1.1 Access-Request packets containing non-obfuscated RADIUS/1.1 Access-Request packets containing non-obfuscated
attributes such as CHAP-Password may be accepted by a RADIUS/1.0 attributes such as CHAP-Password may be accepted by a RADIUS/1.0
server but the response will contain a Response Authenticator (i.e. server, but the response will contain a Response Authenticator (i.e.,
MD5 hash), and not a Token which matches the Token in the request. A MD5 hash) and not a Token that matches the Token in the request. A
similar analysis applies for Access-Request packets containing similar analysis applies for Access-Request packets containing
Service-Type = Authorize-Only. Service-Type = Authorize-Only.
In conclusion, any mismatch of versions between client and server In conclusion, any mismatch of versions between client and server
will result in most request packets being discarded by the server, will result in most request packets being discarded by the server and
and all response packets being discarded by the client. The two all response packets being discarded by the client. Therefore, the
protocols are therefore incompatible, and safe from misconfigurations two protocols are incompatible and safe from misconfigurations or
or erroneous implementations. erroneous implementations.
11. IANA Considerations
IANA is requested to update the "TLS Application-Layer Protocol
Negotiation (ALPN) Protocol IDs" registry with two new entries:
Protocol: RADIUS/1.0
Id. Sequence: 0x72 0x61 0x64 0x69 0x75 0x73 0x2f 0x31 0x2e 0x30
("radius/1.0")
Reference: This document
Protocol: RADIUS/1.1
Id. Sequence: 0x72 0x61 0x64 0x69 0x75 0x73 0x2f 0x31 0x2e 0x31
("radius/1.1")
Reference: This document
12. Acknowledgments
Thanks to Bernard Aboba, Karri Huhtanen, Heikki Vatiainen, Alexander
Clouter, Michael Richardson, Hannes Tschofenig, Matthew Newton, and
Josh Howlett for reviews and feedback.
13. Changelog
(This section to be removed by the RFC editor.)
draft-dekok-radext-sradius-00
Initial Revision
draft-dekok-radext-radiusv11-00
Use ALPN from RFC 7301, instead of defining a new port. Drop the
name "SRADIUS".
Add discussion of Original-Packet-Code
draft-dekok-radext-radiusv11-01
Update formatting.
draft-dekok-radext-radiusv11-02
Add Flag field and description.
Minor rearrangements and updates to text.
draft-dekok-radext-radiusv11-03
Remove Flag field and description based on feedback and expected
use-cases.
Use "radius/1.0" instead of "radius/1"
Consistently refer to the specification as "RADIUSv11", and
consistently quote the ALPN name as "radius/1.1"
Add discussion of future attributes and future crypto-agility
work.
draft-dekok-radext-radiusv11-04
Remove "radius/1.0" as it is unnecessary.
Update Introduction with more historical background, which
motivates the rest of the section.
Change Identifier field to be reserved, as it is entirely unused.
Update discussion on clear text passwords.
Clarify discussion of Status-Server, User-Password, and Tunnel-
Password.
Give high level summary of ALPN, clear up client / server roles,
and remove "radius/1.0" as it is unnecessary.
Add text on RFC6421.
draft-dekok-radext-radiusv11-05
Clarify naming. "radius/1.1" is the ALPN name. "RADIUS/1.1" is
the transport profile.
Clarify that future specifications do not need to make provisions
for dealing with this transport profile.
Typos and word smithing.
Define and use "RADIUS over TLS" instead of RADIUS/(D)TLS.
Many cleanups and rework based on feedback from Matthew Newton.
draft-ietf-radext-radiusv11-00
No changes from previous draft.
draft-ietf-radext-radiusv11-01
Move to "experimental" based on WG feedback.
Many cleanups based on review from Matthew Newton
Removed requirement for supporting TLS-PSK.
This document does not deprecate new cryptographic work in RADIUS.
The "deprecating insecure transports" document does that.
draft-ietf-radext-radiusv11-02
Note that we also update RFC 7930
Minor updates to text.
Add text explaining why "allow" is the default, and how to upgrade
to "require"
Discuss the use of the TLS alert "no_application_protocol" (120),
and its limitations.
Suggest the use of Protocol-Error as an application signal when it
is not possible to send a "no_application_protocol" TLS alert.
Update discussion of Message-Authenticator, and suggest that
RADIUS/1.1 proxies always add Message-Authenticator to Access-
Request packets being sent over UDP or TCP.
Add term "historic RADIUS/TLS" as it is simpler than more awkward
"6614 or 7360".
Re-add ALPN "radius/1.0" based on comments from Heikki. It
signals that the system is ALPN-capable, among other.
draft-ietf-radext-radiusv11-03
Rename to "RADIUS ALPN and removing MD5"
Add a few things missed when re-adding "radius/1.0"
Clarify wording in a number of places.
draft-ietf-radext-radiusv11-04
Address github issues 3..9
draft-ietf-radext-radiusv11-05
Add discussion of Protocol-Error as per-link signalling.
draft-ietf-radext-radiusv11-06
Review from Paul Wouters
Clarify client handling of Protocol-Error
draft-ietf-radext-radiusv11-07
Clarifications as requested by Jan-Frederik
draft-ietf-radext-radiusv11-08
Review from Claudio Allocchio
draft-ietf-radext-radiusv11-09
Review from Barry Lieba
draft-ietf-radext-radiusv11-10 10. IANA Considerations
AD review. IANA has updated the "TLS Application-Layer Protocol Negotiation
(ALPN) Protocol IDs" registry with two new entries:
draft-ietf-radext-radiusv11-11 Protocol: RADIUS/1.0
Identification Sequence: 0x72 0x61 0x64 0x69 0x75 0x73 0x2f 0x31
0x2e 0x30 ("radius/1.0")
Reference: RFC 9765
Review from Eric Vyncke Protocol: RADIUS/1.1
Identification Sequence: 0x72 0x61 0x64 0x69 0x75 0x73 0x2f 0x31
0x2e 0x31 ("radius/1.1")
Reference: RFC 9765
14. References 11. References
14.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", "Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, DOI 10.17487/RFC2865, June 2000, RFC 2865, DOI 10.17487/RFC2865, June 2000,
<https://www.rfc-editor.org/rfc/rfc2865>. <https://www.rfc-editor.org/info/rfc2865>.
[RFC6421] Nelson, D., Ed., "Crypto-Agility Requirements for Remote [RFC6421] Nelson, D., Ed., "Crypto-Agility Requirements for Remote
Authentication Dial-In User Service (RADIUS)", RFC 6421, Authentication Dial-In User Service (RADIUS)", RFC 6421,
DOI 10.17487/RFC6421, November 2011, DOI 10.17487/RFC6421, November 2011,
<https://www.rfc-editor.org/rfc/rfc6421>. <https://www.rfc-editor.org/info/rfc6421>.
[RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga,
"Transport Layer Security (TLS) Encryption for RADIUS", "Transport Layer Security (TLS) Encryption for RADIUS",
RFC 6614, DOI 10.17487/RFC6614, May 2012, RFC 6614, DOI 10.17487/RFC6614, May 2012,
<https://www.rfc-editor.org/rfc/rfc6614>. <https://www.rfc-editor.org/info/rfc6614>.
[RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User [RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User
Service (RADIUS) Protocol Extensions", RFC 6929, Service (RADIUS) Protocol Extensions", RFC 6929,
DOI 10.17487/RFC6929, April 2013, DOI 10.17487/RFC6929, April 2013,
<https://www.rfc-editor.org/rfc/rfc6929>. <https://www.rfc-editor.org/info/rfc6929>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol "Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <https://www.rfc-editor.org/rfc/rfc7301>. July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[RFC7360] DeKok, A., "Datagram Transport Layer Security (DTLS) as a [RFC7360] DeKok, A., "Datagram Transport Layer Security (DTLS) as a
Transport Layer for RADIUS", RFC 7360, Transport Layer for RADIUS", RFC 7360,
DOI 10.17487/RFC7360, September 2014, DOI 10.17487/RFC7360, September 2014,
<https://www.rfc-editor.org/rfc/rfc7360>. <https://www.rfc-editor.org/info/rfc7360>.
[RFC8044] DeKok, A., "Data Types in RADIUS", RFC 8044, [RFC8044] DeKok, A., "Data Types in RADIUS", RFC 8044,
DOI 10.17487/RFC8044, January 2017, DOI 10.17487/RFC8044, January 2017,
<https://www.rfc-editor.org/rfc/rfc8044>. <https://www.rfc-editor.org/info/rfc8044>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
14.2. Informative References 11.2. Informative References
[ASLEAP] Wright, J., "asleap - recovers weak LEAP and PPTP [ASLEAP] "asleap - recovers weak LEAP and PPTP passwords", commit
passwords", n.d., <https://github.com/joswr1ght/asleap>. 254acab, November 2020,
<https://github.com/joswr1ght/asleap>.
[EDUROAM] eduroam, "eduroam", n.d., <https://eduroam.org>. [DEPRECATE-RADIUS]
DeKok, A., "Deprecating Insecure Practices in RADIUS",
Work in Progress, Internet-Draft, draft-ietf-radext-
deprecating-radius-05, 26 November 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-radext-
deprecating-radius-05>.
[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]
Alliance, W. B., "OpenRoaming: One global Wi-Fi network", Wireless Broadband Alliance, "OpenRoaming: One global Wi-
n.d., <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/rfc/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,
<https://www.rfc-editor.org/rfc/rfc2548>. <https://www.rfc-editor.org/info/rfc2548>.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866,
DOI 10.17487/RFC2866, June 2000, DOI 10.17487/RFC2866, June 2000,
<https://www.rfc-editor.org/rfc/rfc2866>. <https://www.rfc-editor.org/info/rfc2866>.
[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege,
M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol
Support", RFC 2868, DOI 10.17487/RFC2868, June 2000, Support", RFC 2868, DOI 10.17487/RFC2868, June 2000,
<https://www.rfc-editor.org/rfc/rfc2868>. <https://www.rfc-editor.org/info/rfc2868>.
[RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and
Accounting (AAA) Transport Profile", RFC 3539, Accounting (AAA) Transport Profile", RFC 3539,
DOI 10.17487/RFC3539, June 2003, DOI 10.17487/RFC3539, June 2003,
<https://www.rfc-editor.org/rfc/rfc3539>. <https://www.rfc-editor.org/info/rfc3539>.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
Dial In User Service) Support For Extensible Dial In User Service) Support For Extensible
Authentication Protocol (EAP)", RFC 3579, Authentication Protocol (EAP)", RFC 3579,
DOI 10.17487/RFC3579, September 2003, DOI 10.17487/RFC3579, September 2003,
<https://www.rfc-editor.org/rfc/rfc3579>. <https://www.rfc-editor.org/info/rfc3579>.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without "Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, DOI 10.17487/RFC5077, Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
January 2008, <https://www.rfc-editor.org/rfc/rfc5077>. January 2008, <https://www.rfc-editor.org/info/rfc5077>.
[RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication [RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication
Dial In User Service (RADIUS) Implementation Issues and Dial In User Service (RADIUS) Implementation Issues and
Suggested Fixes", RFC 5080, DOI 10.17487/RFC5080, December Suggested Fixes", RFC 5080, DOI 10.17487/RFC5080, December
2007, <https://www.rfc-editor.org/rfc/rfc5080>. 2007, <https://www.rfc-editor.org/info/rfc5080>.
[RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
Aboba, "Dynamic Authorization Extensions to Remote Aboba, "Dynamic Authorization Extensions to Remote
Authentication Dial In User Service (RADIUS)", RFC 5176, Authentication Dial In User Service (RADIUS)", RFC 5176,
DOI 10.17487/RFC5176, January 2008, DOI 10.17487/RFC5176, January 2008,
<https://www.rfc-editor.org/rfc/rfc5176>. <https://www.rfc-editor.org/info/rfc5176>.
[RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication [RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication
Protocol Tunneled Transport Layer Security Authenticated Protocol Tunneled Transport Layer Security Authenticated
Protocol Version 0 (EAP-TTLSv0)", RFC 5281, Protocol Version 0 (EAP-TTLSv0)", RFC 5281,
DOI 10.17487/RFC5281, August 2008, DOI 10.17487/RFC5281, August 2008,
<https://www.rfc-editor.org/rfc/rfc5281>. <https://www.rfc-editor.org/info/rfc5281>.
[RFC5931] Harkins, D. and G. Zorn, "Extensible Authentication [RFC5931] Harkins, D. and G. Zorn, "Extensible Authentication
Protocol (EAP) Authentication Using Only a Password", Protocol (EAP) Authentication Using Only a Password",
RFC 5931, DOI 10.17487/RFC5931, August 2010, RFC 5931, DOI 10.17487/RFC5931, August 2010,
<https://www.rfc-editor.org/rfc/rfc5931>. <https://www.rfc-editor.org/info/rfc5931>.
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations
for the MD5 Message-Digest and the HMAC-MD5 Algorithms", for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
RFC 6151, DOI 10.17487/RFC6151, March 2011, RFC 6151, DOI 10.17487/RFC6151, March 2011,
<https://www.rfc-editor.org/rfc/rfc6151>. <https://www.rfc-editor.org/info/rfc6151>.
[RFC6218] Zorn, G., Zhang, T., Walker, J., and J. Salowey, "Cisco [RFC6218] Zorn, G., Zhang, T., Walker, J., and J. Salowey, "Cisco
Vendor-Specific RADIUS Attributes for the Delivery of Vendor-Specific RADIUS Attributes for the Delivery of
Keying Material", RFC 6218, DOI 10.17487/RFC6218, April Keying Material", RFC 6218, DOI 10.17487/RFC6218, April
2011, <https://www.rfc-editor.org/rfc/rfc6218>. 2011, <https://www.rfc-editor.org/info/rfc6218>.
[RFC6613] DeKok, A., "RADIUS over TCP", RFC 6613, [RFC6613] DeKok, A., "RADIUS over TCP", RFC 6613,
DOI 10.17487/RFC6613, May 2012, DOI 10.17487/RFC6613, May 2012,
<https://www.rfc-editor.org/rfc/rfc6613>. <https://www.rfc-editor.org/info/rfc6613>.
[RFC7585] Winter, S. and M. McCauley, "Dynamic Peer Discovery for [RFC7585] Winter, S. and M. McCauley, "Dynamic Peer Discovery for
RADIUS/TLS and RADIUS/DTLS Based on the Network Access RADIUS/TLS and RADIUS/DTLS Based on the Network Access
Identifier (NAI)", RFC 7585, DOI 10.17487/RFC7585, October Identifier (NAI)", RFC 7585, DOI 10.17487/RFC7585, October
2015, <https://www.rfc-editor.org/rfc/rfc7585>. 2015, <https://www.rfc-editor.org/info/rfc7585>.
[RFC7593] Wierenga, K., Winter, S., and T. Wolniewicz, "The eduroam [RFC7593] Wierenga, K., Winter, S., and T. Wolniewicz, "The eduroam
Architecture for Network Roaming", RFC 7593, Architecture for Network Roaming", RFC 7593,
DOI 10.17487/RFC7593, September 2015, DOI 10.17487/RFC7593, September 2015,
<https://www.rfc-editor.org/rfc/rfc7593>. <https://www.rfc-editor.org/info/rfc7593>.
[RFC7930] Hartman, S., "Larger Packets for RADIUS over TCP", [RFC7930] Hartman, S., "Larger Packets for RADIUS over TCP",
RFC 7930, DOI 10.17487/RFC7930, August 2016, RFC 7930, DOI 10.17487/RFC7930, August 2016,
<https://www.rfc-editor.org/rfc/rfc7930>. <https://www.rfc-editor.org/info/rfc7930>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
Acknowledgments
Thanks to Bernard Aboba, Karri Huhtanen, Heikki Vatiainen, Alexander
Clouter, Michael Richardson, Hannes Tschofenig, Matthew Newton, and
Josh Howlett for reviews and feedback.
Author's Address Author's Address
Alan DeKok Alan DeKok
FreeRADIUS FreeRADIUS
Email: aland@freeradius.org Email: aland@freeradius.org
 End of changes. 286 change blocks. 
881 lines changed or deleted 720 lines changed or added

This html diff was produced by rfcdiff 1.48.