Alan said:
I'm a bit more concerned about TOFU with PSKs. The server would still have to know what the PSK is before it can accept the new connection. The most I could see happening is that the initial connection gets rejected, but the server logs information about the client. e.g. "PSK Identity FOO was used from IP address BAR, but there is no known PSK associated with it".
The administrator could then use this log message to determine which PSKs should be provisioned.
" Perhaps something like:
The intent for TLS-PSK is to be used in networks where the addresses of client and server are known, as with RADIUS/UDP. TLS-PSK is not suitable for situations where clients dynamically discovers servers, as there is no way for the client to dynamically determine which PSK should be used with a new server (or vice versa). In contrast, [RFC7585] dynamic discovery allows for a client or server to authenticate previously unknown server or client, as the parties can be issued a certificate by a known Certification Authority (CA)."
[BA] Yes - this is much better.
" RFC 9258 should help. I'll add a note.
I'm a bit more concerned about TOFU with PSKs. The server would still have to know what the PSK is before it can accept the new connection. The most I could see happening is that the initial connection gets rejected, but the server logs information about the client. e.g. "PSK Identity FOO was used from IP address BAR, but there is no known PSK associated with it".
The administrator could then use this log message to determine which PSKs should be provisioned.
On a related note, the document could discuss client back-off for failed connections."
[BA] Thanks. Might be worth explaining the issues/risks with TOFU. Not sure IT admins will be comfortable with TOFU for large deployments, particularly if RFC 9258 offers a viable alternative.
" Perhaps
Even where [RFC7585] dynamic discovery is not used, it is NOT RECOMMENDED to use TLS-PSK to be used across the wider Internet. Such uses would tend towards unrelated organizations sharing a known PSK, which would make it easier for a client to impersonate a server, and vice versa. In contrast, when certificates are used, such impersonations are impossible. When TLS-PSK is used in an environment where both client and server are part of the same organization, then impersonations only affect that organization."
[BA] It's fair to say that TLS-PSK is NOT RECOMMENDED for "unrelated organizations" cooperating to share network resources (such as EDUROAM) since that would imply sharing TLS-PSKs across organizational boundaries.
However if the clients and servers are in the same organization (e.g. an enterprise WiFi network with a cloud server), and the IT admins follow the advice in the document, is the reasoning against TLS-PSK as solid?
While it's possible for clients to impersonate servers in a corpnet scenario, that kind of attack seems like a low risk compared with the other security issues addressed by RADIUS over (D)TLS. The clients are typically very under powered compared to servers, run proprietary operating systems, and are on different networks than the servers, etc. So seems to me that TLS-PSK deployment should be greatly preferred over conventional RADIUS.
"I believe so. If the TLS WG didn't think TLS-PSK was secure, they wouldn't have standardized it. I think..."
[BA] If TLS-PSK over the Internet can be securely deployed by a single organization with the guidance you provide, then I'd suggest stating the secure scenario clearly and making the guidance for the single org scenario a SHOULD or MUST. This would be more clear than saying that TLS-PSK is NOT RECOMMENDED over the Internet for all deployment scenarios.
"Perhaps
The benefits of TLS-PSK are that its operational processes mirror that of RADIUS/UDP, and therefore it does not require any additional processes such as when certificates are used."
[BA] "mirror" might be too strong unless RFC 9258 can make "set and forget" possible across TLS versions. Instead of "and therefore...' you might say:
". In contrast, certificate deployments can raise additional operational issues, as noted in Section X".
On Sat, Sep 21, 2024 at 12:37 PM Alan DeKok <aland@xxxxxxxxxxxxxxxxxxx> wrote:
On Sep 20, 2024, at 4:35 PM, Bernard Aboba <bernard.aboba@xxxxxxxxx> wrote:
> "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?
Perhaps something like:
The intent for TLS-PSK is to be used in networks where the addresses of client and server are known, as with RADIUS/UDP. TLS-PSK is not suitable for situations where clients dynamically discover servers, as there is no way for the client to dynamically determine which PSK should be used with a new server (or vice versa). In contrast, [RFC7585] dynamic discovery allows for a client or server to authenticate previously unknown server or client, as the parties can be issued a certificate by a known Certification Authority (CA).
> 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.
Sure.
> 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.
Agreed. I'll tweak the wording.
> 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?
RFC 9258 should help. I'll add a note.
I'm a bit more concerned about TOFU with PSKs. The server would still have to know what the PSK is before it can accept the new connection. The most I could see happening is that the initial connection gets rejected, but the server logs information about the client. e.g. "PSK Identity FOO was used from IP address BAR, but there is no known PSK associated with it".
The administrator could then use this log message to determine which PSKs should be provisioned.
On a related note, the document could discuss client back-off for failed connections.
> 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:
Perhaps
Even where [RFC7585] dynamic discovery is not used, it is NOT RECOMMENDED to use TLS-PSK to be used across the wider Internet. Such uses would tend towards unrelated organizations sharing a known PSK, which would make it easier for a client to impersonate a server, and vice versa. In contrast, when certificates are used, such impersonations are impossible. When TLS-PSK is used in an environment where both client and server are part of the same organization, then impersonations only affect that organization.
> "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?
I believe so. If the TLS WG didn't think TLS-PSK was secure, they wouldn't have standardized it. I think...
> "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.
Perhaps
The benefits of TLS-PSK are that its operational processes mirror that of RADIUS/UDP, and therefore it does not require any additional processes such as when certificates are used.
Alan DeKok.
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
