Review of: draft-ietf-radext-tls-psk
Reviewer: Bernard Aboba
Status: Has Issues
Summary
While the document addresses some of the issues that have blocked deployment of RADIUS over (D)TLS with TLS-PSK, some significant operational issues remain. Also, the document appears to contradict itself on the applicability of TLS-PSK on the wider Internet.
Review
Section 1
"The intent for TLS-PSK is for it to be used in internal / secured networks, where clients come from a small number of known locations. This situation mirrors the use-case of shared secrets.
TLS-PSK is not suitable where servers are not statically known, such as with dynamic server lookups [RFC7585]."
[BA] Are you saying that TLS-PSK is not appropriate for use with a "RADIUS over (D)TLS" server cloud deployment? Section 6.2 provides a recommendation that would allow deployment over the Internet, which seems contradictory. I agree that conventional RADIUS is not appropriate for a cloud-server deployment but presumably that is the problem that RADIUS over (D)TLS is trying to fix.
Is the idea of a "secured network" credible anymore? The movement toward "Zero Trust" security which seems to be in vogue today is based on the idea that no network is secure.
Can you define the meaning of "statically known"? Do you mean providing the server IP address as we do today in RADIUS? Or could this also mean configuring a domain name?
Reviewer: Bernard Aboba
Status: Has Issues
Summary
While the document addresses some of the issues that have blocked deployment of RADIUS over (D)TLS with TLS-PSK, some significant operational issues remain. Also, the document appears to contradict itself on the applicability of TLS-PSK on the wider Internet.
Review
Section 1
"The intent for TLS-PSK is for it to be used in internal / secured networks, where clients come from a small number of known locations. This situation mirrors the use-case of shared secrets.
TLS-PSK is not suitable where servers are not statically known, such as with dynamic server lookups [RFC7585]."
[BA] Are you saying that TLS-PSK is not appropriate for use with a "RADIUS over (D)TLS" server cloud deployment? Section 6.2 provides a recommendation that would allow deployment over the Internet, which seems contradictory. I agree that conventional RADIUS is not appropriate for a cloud-server deployment but presumably that is the problem that RADIUS over (D)TLS is trying to fix.
Is the idea of a "secured network" credible anymore? The movement toward "Zero Trust" security which seems to be in vogue today is based on the idea that no network is secure.
Can you define the meaning of "statically known"? Do you mean providing the server IP address as we do today in RADIUS? Or could this also mean configuring a domain name?
Section 3
"For example, unlike shared secrets, certificates expire. This expiration means that a working system using TLS can suddenly stop working. Managing this expiration can require additional notification APIs on RADIUS clients and servers which were previously not required when shared secrets were used."
[BA] I'd suggest that you distinguish between client and server certificate maintenance issues here. Servers are typically much smaller in number than clients and updating server certificates can be automated.
Keeping certificates up to date in a large client deployment (which could include thousands of devices) is another problem entirely. In such a situation, the clients might have limited resources, might run on a proprietary OS without the ability to run certificate update scripts. Unless the devices are enterprise class,there may be no management software offering.
Keeping certs up to date might even be challenging for a small deployment of a dozen devices, which might cause admins to prefer a 'set and forget' model of provisioning. Whether that is possible with TLS-PSK is therefore an important question.
Section 4.1
"An implementation MUST NOT use the same PSK for TLS 1.3 and for earlier versions of TLS. This requirement prevents reuse of a PSK with multiple TLS versions, which prevents the attacks discussed in [RFC8446], Appendix E.7. The exact manner in which this requirement is enforced is implementation-specific. One possibility is to have two different PSKs. Another possibility is to forbid the use of TLS 1.3, or to forbid the use of TLS versions less than TLS 1.3."
[BA] This advice seems sound, but in practice, having to provide a new TLS-PSK for each new version of TLS will be an operational challenge in large (or even small) client deployments. I'm concerned that admins used to the "set and forget" model of conventional RADIUS won't heed this advice.
Is there a way to address this operational problem? For example, could PSKs be provisioned via Trust on First Use (TOFU)? Can External PSK importers (RFC 9258) help?
"For example, unlike shared secrets, certificates expire. This expiration means that a working system using TLS can suddenly stop working. Managing this expiration can require additional notification APIs on RADIUS clients and servers which were previously not required when shared secrets were used."
[BA] I'd suggest that you distinguish between client and server certificate maintenance issues here. Servers are typically much smaller in number than clients and updating server certificates can be automated.
Keeping certificates up to date in a large client deployment (which could include thousands of devices) is another problem entirely. In such a situation, the clients might have limited resources, might run on a proprietary OS without the ability to run certificate update scripts. Unless the devices are enterprise class,there may be no management software offering.
Keeping certs up to date might even be challenging for a small deployment of a dozen devices, which might cause admins to prefer a 'set and forget' model of provisioning. Whether that is possible with TLS-PSK is therefore an important question.
Section 4.1
"An implementation MUST NOT use the same PSK for TLS 1.3 and for earlier versions of TLS. This requirement prevents reuse of a PSK with multiple TLS versions, which prevents the attacks discussed in [RFC8446], Appendix E.7. The exact manner in which this requirement is enforced is implementation-specific. One possibility is to have two different PSKs. Another possibility is to forbid the use of TLS 1.3, or to forbid the use of TLS versions less than TLS 1.3."
[BA] This advice seems sound, but in practice, having to provide a new TLS-PSK for each new version of TLS will be an operational challenge in large (or even small) client deployments. I'm concerned that admins used to the "set and forget" model of conventional RADIUS won't heed this advice.
Is there a way to address this operational problem? For example, could PSKs be provisioned via Trust on First Use (TOFU)? Can External PSK importers (RFC 9258) help?
Section 6.2
"Even where [RFC7585] dynamic discovery is not used, servers SHOULD NOT permit TLS-PSK to be used across the wider Internet. The intent for TLS-PSK is for it to be used in internal / secured networks, where clients come from a small number of known locations. In contrast, certificates can be generated and assigned to clients without any interaction with the RADIUS server. Therefore if the RADIUS server needs to accept connections from clients at unknown locations, a more secure method is to use client certificates."
[BA] Later in this same section, there is advice for use of TLS-PSK over the Internet, which
seems to contradict this paragraph:
"Where TLS-PSK is used across the Internet, PSKs MUST contain at least 256 bits of entropy."
Is TLS-PSK secure across the Internet if this recommendation is followed? If so, why
recommend against its use?
"The benefits of TLS-PSK are in easing management and in administrative overhead, not in
securing traffic from resourceful attackers."
[BA] This statement is provided without references or detail on the potential vulnerabilities.
In "Zero Trust" environments, we assume that an attacker is always present, so if TLS-PSK
cannot be used in that case it would be considered undeployable.
"Even where [RFC7585] dynamic discovery is not used, servers SHOULD NOT permit TLS-PSK to be used across the wider Internet. The intent for TLS-PSK is for it to be used in internal / secured networks, where clients come from a small number of known locations. In contrast, certificates can be generated and assigned to clients without any interaction with the RADIUS server. Therefore if the RADIUS server needs to accept connections from clients at unknown locations, a more secure method is to use client certificates."
[BA] Later in this same section, there is advice for use of TLS-PSK over the Internet, which
seems to contradict this paragraph:
"Where TLS-PSK is used across the Internet, PSKs MUST contain at least 256 bits of entropy."
Is TLS-PSK secure across the Internet if this recommendation is followed? If so, why
recommend against its use?
"The benefits of TLS-PSK are in easing management and in administrative overhead, not in
securing traffic from resourceful attackers."
[BA] This statement is provided without references or detail on the potential vulnerabilities.
In "Zero Trust" environments, we assume that an attacker is always present, so if TLS-PSK
cannot be used in that case it would be considered undeployable.
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
