Internet DRAFT - draft-dekok-radext-tls-psk
draft-dekok-radext-tls-psk
RADEXT Working Group A. DeKok
Internet-Draft FreeRADIUS
Intended status: Informational 3 March 2023
Expires: 4 September 2023
RADIUS and TLS-PSK
draft-dekok-radext-tls-psk-00
Abstract
This document gives implementation and operational considerations for
using TLS-PSK with RADIUS/TLS (RFC6614) and RADIUS/DTLS (RFC7360).
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-dekok-radext-tls-psk/.
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/.
Source for this draft and an issue tracker can be found at
https://github.com/freeradius/radext-tls-psk.git.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
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
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 4 September 2023.
DeKok Expires 4 September 2023 [Page 1]
Internet-Draft RADIUS and TLS-PSK March 2023
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Guidance for RADIUS clients . . . . . . . . . . . . . . . . . 3
4.1. PSK Identities . . . . . . . . . . . . . . . . . . . . . 4
5. Guidance for RADIUS Servers . . . . . . . . . . . . . . . . . 4
5.1. Identifying and filtering clients . . . . . . . . . . . . 4
6. Shared Secrets . . . . . . . . . . . . . . . . . . . . . . . 5
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . 6
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 6
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
12.1. Normative References . . . . . . . . . . . . . . . . . . 6
12.2. Informative References . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
[RFC6614] and [RFC7360] define TLS and DTLS transports for RADIUS
[RFC2865]. However, neither of those documents discuss how to use
TLS-PSK. This document gives implementation and operational
considerations for using TLS-PSK with RADIUS.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
DeKok Expires 4 September 2023 [Page 2]
Internet-Draft RADIUS and TLS-PSK March 2023
TBD
3. History
Certificates are hard to manage, but there is no guidance in
[RFC6614] and [RFC7360] for using TLS-PSK.
4. Guidance for RADIUS clients
TLS uses certificates in most common uses. However, we recognize
that it may be difficult to fully upgrade client implementations to
allow for certificates to be used with RADIUS/TLS and RADIUS/DTLS.
Client implementations therefore MUST allow the use of a pre-shared
key (TLS-PSK). The client implementation can then expose a flag "TLS
yes / no", and then a shared secret (now PSK) entry field.
Any shared secret used for RADIUS/UDP or RADIUS/TLS [RFC6613] MUST
NOT be used for TLS-PSK.
Implementations MUST support PSKs of at least 32 octets, and SHOULD
support PSKs of 64 octets. Implementations MUST require that PSKs be
at least 16 octets in length. That is, short PSKs MUST NOT be
permitted to be used.
Administrators SHOULD use PSKs of at least 24 octets, generated using
a source of secure random numbers. The script given above can again
be used.
We also incorporate by reference the requirements of Section 10.2 of
[RFC7360] when using PSKs.
The issue of using PSKs in multiple TLS versions is discussed in
[RFC8446] Section E.7, which notes:
Implementations can ensure safety from cross-protocol related output
by not reusing PSKs between TLS 1.3 and TLS 1.2.
It would be unnecessarily complex for management interfaces and
administrators to manage multiple PSKs depending on the TLS version.
Therefore, we mandate that when TLS-PSK is used, TLS 1.3 or later
MUST be used in RADIUS/TLS and RADIUS/DTLS.
Implementations MUST use ECDH cipher suites:
* TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256
* TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA256
DeKok Expires 4 September 2023 [Page 3]
Internet-Draft RADIUS and TLS-PSK March 2023
* TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA384
* TBD: other TLS ECDH PSK suites
4.1. PSK Identities
[RFC6614] is silent on the subject of PSK identities, which is an
issue that we correct here. Guidance is required on the use of PSK
identities, as the need to manage identities associated with PSK is a
new requirement for NAS management interfaces, and is a new
requirement for RADIUS servers.
RADIUS systems implementing TLS-PSK MUST support identities as per
[RFC4279] Section 5.3, and MUST enable configuring TLS-PSK identities
in management interfaces as per [RFC4279] Section 5.4.
A RADIUS client implementing TLS-PSK MUST update their management
interfaces and application programming interfaces (APIs) to label the
PSK field as "PSK" or "TLS-PKS, and MUST NOT label the PSK field as
"shared secret".
Where dynamic server lookups [RFC7585] are not used, RADIUS clients
MUST still permit the configuration of a RADIUS server IP address.
5. Guidance for RADIUS Servers
The following section(s) describe guidance for RADIUS server
implementationas and deployments.
5.1. Identifying and filtering clients
When a RADIUS server implements TLS-PSK, it MUST use the PSK identity
as the logical identifier for a RADIUS client instead of the IP
address, as was done with RADIUS/UDP. That is, instead of
associating a source IP address with a shared secret, the RADIUS
server instead associates a PSK identity with a pre-shared key. In
effect, the PSK identity replaces the source IP address of the
connection as the client identifier.
This requirement does not prevent the server from using source IP
addresses for filtering or client identification. Instead, it says
that servers are no longer required to use solely the source IP
address for client identification and filtering.
RADIUS servers MUST be able to look up PSK identity in a subsystem
which then returns the actual PSK.
DeKok Expires 4 September 2023 [Page 4]
Internet-Draft RADIUS and TLS-PSK March 2023
RADIUS servers MUST support IP address and network filtering of the
source IP address for all TLS connections. There is rarely a reason
for a RADIUS server to allow connections from the entire Internet,
and there are many reasons to limit permitted connections to a small
list of networks.
RADIUS servers SHOULD be able to limit certain PSK identifiers to
certain network ranges or IP addresses. This filtering can catch
configuration errors. That is, if a NAS is known to have a dynamic
IP address within a particular subnet, the server should limit use of
the NASes PSK to that subnet.
Note that as some clients may have dynamic IP addresses, it is
possible for a one PSK identity to appear at different source IP
addresses over time. In addition, as there may be many clients
behind one NAT gateway, there may be multiple RADIUS clients using
one public IP address. RADIUS servers MUST support multiple PSKs at
one source IP address, and MUST support a unique PSK identity for
each unique client which is deployed in such a scenario.
RADIUS servers SHOULD tie PSK identities to a particular permitted IP
address or permitted network, as doing so will lower the risk if a
PSK is leaked. RADIUS servers MUST permit multiple clients to share
one permitted IP address or network.
A RADIUS server which accepts TLS-PSK MUST support a unique PSK
identifier per RADIUS client. There is no reason to use the same
identifier for multiple clients. A RADIUS server which accepts TLS-
PSK MUST have a unique PSK per RADIUS client.
6. Shared Secrets
Any shared secret used for RADIUS/UDP or RADIUS/TLS MUST NOT be used
for TLS-PSK.
It is RECOMMENDED that RADIUS clients and server track all used
shared secrets and PSKs, and then verify that the following
requirements all hold true:
* no shared secret is used for more than one RADIUS client
* no PSK is used for more than one RADIUS cleint
* no shared secret is used as a PSK
* no PSK is used as a shared secret
DeKok Expires 4 September 2023 [Page 5]
Internet-Draft RADIUS and TLS-PSK March 2023
7. Privacy Considerations
We make no changes over [RFC6614] and [RFC7360].
8. Security Considerations
The primary focus of this document is addressing security
considerations for RADIUS.
9. IANA Considerations
There are no IANA considerations in this document.
RFC Editor: This section may be removed before final publication.
10. Acknowledgements
TBD.
11. Changelog
12. References
12.1. Normative References
[BCP14] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, DOI 10.17487/RFC2865, June 2000,
<https://www.rfc-editor.org/info/rfc2865>.
[RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key
Ciphersuites for Transport Layer Security (TLS)",
RFC 4279, DOI 10.17487/RFC4279, December 2005,
<https://www.rfc-editor.org/info/rfc4279>.
[RFC7585] Winter, S. and M. McCauley, "Dynamic Peer Discovery for
RADIUS/TLS and RADIUS/DTLS Based on the Network Access
Identifier (NAI)", RFC 7585, DOI 10.17487/RFC7585, October
2015, <https://www.rfc-editor.org/info/rfc7585>.
DeKok Expires 4 September 2023 [Page 6]
Internet-Draft RADIUS and TLS-PSK March 2023
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
12.2. Informative References
[RFC6613] DeKok, A., "RADIUS over TCP", RFC 6613,
DOI 10.17487/RFC6613, May 2012,
<https://www.rfc-editor.org/info/rfc6613>.
[RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga,
"Transport Layer Security (TLS) Encryption for RADIUS",
RFC 6614, DOI 10.17487/RFC6614, May 2012,
<https://www.rfc-editor.org/info/rfc6614>.
[RFC7360] DeKok, A., "Datagram Transport Layer Security (DTLS) as a
Transport Layer for RADIUS", RFC 7360,
DOI 10.17487/RFC7360, September 2014,
<https://www.rfc-editor.org/info/rfc7360>.
Author's Address
Alan DeKok
FreeRADIUS
Email: aland@freeradius.org
DeKok Expires 4 September 2023 [Page 7]
